Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wSgdc-0001VB-0K for pgsql-hackers@arkaria.postgresql.org; Thu, 28 May 2026 19:43:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wSgcZ-000OEa-1n for pgsql-hackers@arkaria.postgresql.org; Thu, 28 May 2026 19:42:23 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wSgcY-000OER-1c for pgsql-hackers@lists.postgresql.org; Thu, 28 May 2026 19:42:23 +0000 Received: from fhigh-b6-smtp.messagingengine.com ([202.12.124.157]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wSgcV-000000001MW-1Imh for pgsql-hackers@postgresql.org; Thu, 28 May 2026 19:42:22 +0000 Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfhigh.stl.internal (Postfix) with ESMTP id 9B6E77A0067; Thu, 28 May 2026 15:42:15 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-06.internal (MEProxy); Thu, 28 May 2026 15:42:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1779997335; x=1780083735; bh=BqfR93UTfq6Ik3X/CK1zM9sNtMH1+eJVqB3arBRa4v0=; b= QhT4f6oAGvgzAoigmDBroVj4AO/T2Y/fUERVyLbkGjLuGLv59QOcdVeO+fDde9Wt nhYhT9kP9g6dwcPhL5eCZL7VgTG29pcVv8gyPBtPB/lPtg2K4JGu4SbJsK1oykAu qgZcODGo/ZTTmrnG9s3EiwFeNDVjIJ1pCZ1g0l6y3jUZ9pPSwWGxkukhlnubz/+z g5Syy8uZzEKRNFEFJQBmyvZT6RI7k0h/AdDHDras5atO/If3NPUl85OgAc8rUq6V ipxDbJnS8qVVigkJNupbhRVwc+QsFVHuF+OHknXa3YiBCVsVt4Pc2cTnNVJ2x+ra 5zUrfWIVR8resnhXOn9bAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1779997335; x= 1780083735; bh=BqfR93UTfq6Ik3X/CK1zM9sNtMH1+eJVqB3arBRa4v0=; b=T LsDAfWV1mdljRqxyW960ADFUCjlwiHBTyMeJQiTR/hkwDZmZL33wYm5srRD+OSqT Wg8gc91NlVQgX/DOsPHfCX1mAZgfvmv8hMzFCzBsIWHPIGMAqK6JZT1xvg/F0wiF std40bE3Fs5E0Gwp0CCHdWV7gFOSTg8/kYYp+IuW2mcsA/R9nmQ+K1udxBG0l+Vs tlrsZ+SGWHJ35CuUO+JHxMi3hzju06M3+tJbri8ClFIm3IpTXsQw5aT13G0h65uo B/tcEtr/fpzJs6hoyy+JhPahhVw9DyyYnTZ0wIFt5lecxbBMPfR/7ZUYwFHo4v5F 6FTl02VxFgCf+ZmS2BBzw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTE43Iny1QqhITlNLaoWVQ/oSSSqJ9Hg2ekXYc+6uMUgVZBuR9tJe3IzuFle++iM4L 3J+NImajzP2HbmnbCEAmLtJQ7bKtmt1wjFXkjOlhV7A/4O/121WPHpBjtN5TRYKWKcDN4C sZzFHJbYkls3kN0X4Se3j/DKSAwu4ihDj8JY9BYG+06cnwHami7BVqHY59Uj3gOe/0y48s Vu9mjhk0UhCiHbbf7viksJR1bntiZJ5/IZgcXUCH2UaxWL8BoTsvA8+NMGBj1GZGMOCw3q XOErGCphVKDnHIw1GqlsCFFne4ZzLe9CvKQJDIVtfFvz34LVq59kNhIajXKk7/vU3w33oE d9DqsBncEwWJQ2X6mNGYknV0JQatvqtpcNx7JojSFBY0FoMapeawxRQClxj6WrHPxQl3Rp o3tnq8HrcIBicb2iLvYIlixJ8afiiwbDaHT9mjaZqiX7odWilNNEqKINmU4f4fYT21HY0Y EFzU5A/1rN4w9kSip36DuuEkgpg2I2H5s7AKAIbZlpCTY810EGu/6jcaWg+6UEV/lZIOOi 6IpV9W0dX4cor+IonT81ukzDJNBzqnVwOb1kRt5fAIRT7YUDDNy2+ttcKvZheJFsZIDBwG CT0ghcgOQ2L63rooYziD7PPcEs5jsGAcrHaD55Kybhgas6wtV1gzQ1XoJJkQ X-ME-Proxy: Feedback-ID: id4a34324:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 28 May 2026 15:42:14 -0400 (EDT) Date: Thu, 28 May 2026 15:42:13 -0400 From: Andres Freund To: =?utf-8?Q?=C3=81lvaro?= Herrera Cc: Nazir Bilal Yavuz , Jelte Fennema-Nio , Thomas Munro , pgsql-hackers@postgresql.org, Zsolt Parragi , Peter Eisentraut Subject: Re: Heads Up: cirrus-ci is shutting down June 1st Message-ID: <3wulk62iw2c5n3bxnkdpumm4updcbw3id3ahwkq2566q7m7jbj@qkbdz4rrukbw> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On 2026-05-28 20:42:41 +0200, Álvaro Herrera wrote: > On 2026-May-28, Álvaro Herrera wrote: > > > Hi, I just pushed this to github to see how it would behave. In case > > anyone is curious, the run is here, > > > > https://github.com/alvherre/postgres/actions/runs/26591496806 > > > > Overall I get the impression that it's much slower than Cirrus. [...] > Macos took 10 minutes just for the macports install! Cirrus completed the > same build in 18:32, https://cirrus-ci.com/build/4817054382948352 FWIW, the macports install should be down to ~5s on subsequent runs. Doing that uncached was also rather slow on cirrus. > > If I read the Github docs correctly, I get 2000 run minutes for free > > each month. That would mean I can run at most some ... 15 runs per > > month? That sounds quite limiting. My understanding is that the 2000 minutes is the limit for *private* repositories: [1] "Use of the standard GitHub-hosted runners is free and unlimited on public repositories." The concurrency limits are also pretty generous: [2], 20 jobs of 4 cores each. If you look at the limits of other providers, they are much much lower. Like 400 CPU minutes for gitlab (so about 100 minutes of 4 core VMs). On 2026-05-28 20:11:45 +0200, Álvaro Herrera wrote: > Hi, I just pushed this to github to see how it would behave. In case > anyone is curious, the run is here, > > https://github.com/alvherre/postgres/actions/runs/26591496806 > > Overall I get the impression that it's much slower than Cirrus. 20 > minutes in, only the two "Linux - Meson" build finished, in 14 and 17 > minutes respectively. It's definitely slower. I've not fully analyzed why, my suspicion is that we end up being rather terribly IO bound - we used bigger and faster disks on cirrus than we have access to with github hosted runners (there are large runners with more storage, but that's not free). A full testrun on master creates about 36GB of data directories. If individual tests are fast, that's often not *that* bad, because the tests are over before linux decides to flush out the data, and then linux never needs to write that data back, because we remove the data directories immediately. But once you get to the point that several tests take more than 30s (the default time after which linux writes dirty data back) or enough dirty data accumulates (20% of memory IIRC), you have a lot of IO. My buildfarm host, which hosts quite a few animals, got a new disk within the last year. Here's what smartctl says about disk IO: Data Units Read: 43,513,034 [22.2 TB] Data Units Written: 6,062,401,949 [3.10 PB] A nice indication of how much our tests end up writing... I think we're going to have to fix that on our end to some degree. 36GB of data being written each test run is just not reasonable. We spin up quite a few separate data directories for tests that take well under a second. That's just a very unfavorable ratio. In [3] I wrote > I think we need to combine about half the modules in src/test/modules, the > current course is absurd: > > 16: 37 > 17: 46 > 18: 49 > dev: 62 Greetings, Andres Freund [1] https://docs.github.com/en/actions/reference/runners/github-hosted-runners#standard-github-hosted-runners-for-public-repositories [2] https://docs.github.com/en/actions/reference/limits#job-concurrency-limits-for-github-hosted-runners [3] https://postgr.es/m/hp4xznm7dqt4ediyhezqysf22eljvu3mucbzsgvgehc6j2hk5v%40laslwlkyixfg