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.94.2) (envelope-from ) id 1sqDW0-007uuY-3g for pgsql-hackers@arkaria.postgresql.org; Mon, 16 Sep 2024 15:19:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sqDVy-00Fxsu-Ob for pgsql-hackers@arkaria.postgresql.org; Mon, 16 Sep 2024 15:19:46 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sqDVy-00Fxsm-Em for pgsql-hackers@lists.postgresql.org; Mon, 16 Sep 2024 15:19:46 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sqDVv-001Spw-Eq for pgsql-hackers@lists.postgresql.org; Mon, 16 Sep 2024 15:19:45 +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 48GFJg1H1156796; Mon, 16 Sep 2024 11:19:42 -0400 From: Tom Lane To: Sven Klemm cc: Wolfgang Walther , pgsql-hackers@lists.postgresql.org Subject: Re: Regression tests fail with tzdata 2024b In-reply-to: References: <0a997455-5aba-4cf2-a354-d26d8bcbfae6@technowledgy.de> <441306.1726346239@sss.pgh.pa.us> <38e73fef-f19b-4835-b353-a110db6c8318@technowledgy.de> <1043017.1726463364@sss.pgh.pa.us> Comments: In-reply-to Sven Klemm message dated "Mon, 16 Sep 2024 10:33:56 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1156794.1726499982.1@sss.pgh.pa.us> Date: Mon, 16 Sep 2024 11:19:42 -0400 Message-ID: <1156795.1726499982@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Sven Klemm writes: > This is an unfortunate change as this will break extensions tests using > pg_regress for testing. We run our tests against multiple minor versions > and this getting backported means our tests will fail with the next minor > pg release. Is there a workaround available to make the timezone for > pg_regress configurable without going into every test? Configurable to what? If your test cases are dependent on the historical behavior of PST8PDT, you're out of luck, because that simply isn't available anymore (or won't be once 2024b reaches your platform, anyway). regards, tom lane