Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lUW1H-00078N-2c for pgsql-committers@arkaria.postgresql.org; Thu, 08 Apr 2021 14:52:31 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lUW1E-0003JK-UF for pgsql-committers@arkaria.postgresql.org; Thu, 08 Apr 2021 14:52:28 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lUW1E-0003JD-P4 for pgsql-committers@lists.postgresql.org; Thu, 08 Apr 2021 14:52:28 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lUW18-0005pT-GP for pgsql-committers@lists.postgresql.org; Thu, 08 Apr 2021 14:52:27 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 138EqG2D1846549; Thu, 8 Apr 2021 10:52:16 -0400 From: Tom Lane To: Andrew Dunstan cc: Andres Freund , David Rowley , Peter Eisentraut , pgsql-committers@lists.postgresql.org Subject: Re: pgsql: SQL-standard function body In-reply-to: <42affe76-48c4-a78c-e548-83a16b806af2@dunslane.net> References: <20210407225806.majgznh4lk34hjvu@alap3.anarazel.de> <1730972.1617836766@sss.pgh.pa.us> <20210408015017.yb2tb324y6zt4o66@alap3.anarazel.de> <42affe76-48c4-a78c-e548-83a16b806af2@dunslane.net> Comments: In-reply-to Andrew Dunstan message dated "Thu, 08 Apr 2021 10:12:22 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1846547.1617893536.1@sss.pgh.pa.us> Date: Thu, 08 Apr 2021 10:52:16 -0400 Message-ID: <1846548.1617893536@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Andrew Dunstan writes: > On 4/7/21 9:50 PM, Andres Freund wrote: >> I've wondered about that too. Perhaps we could reuse the pg_upgrade run? > Honestly I'd prefer it if we could get rid of the rerun of 'make check' > by pg_upgrade's test.sh and instead upgrade the data directory made by > the earlier 'make check' run if it's still there (which would mean we'd > need to stop it being deleted). Good idea as far as speeding check-world and buildfarm runs, but I wonder if we wouldn't be losing test coverage. Seeing the number of times that buildfarm runs have gotten through "make check" only to fail at the re-run in pg_upgrade, it seems clear to me that there is something different about the execution environment in the latter case. I've never been able to pin down quite what :-( regards, tom lane