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 1t6HnL-00Bu4f-1g for pgsql-committers@arkaria.postgresql.org; Wed, 30 Oct 2024 23:08:07 +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 1t6HnI-00DLPN-He for pgsql-committers@arkaria.postgresql.org; Wed, 30 Oct 2024 23:08:04 +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.94.2) (envelope-from ) id 1t6HnI-00DLP9-AI for pgsql-committers@lists.postgresql.org; Wed, 30 Oct 2024 23:08:04 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t6HnC-003tfx-ID for pgsql-committers@lists.postgresql.org; Wed, 30 Oct 2024 23:08:04 +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 49UN7ua7871449; Wed, 30 Oct 2024 19:07:56 -0400 From: Tom Lane To: Andrew Dunstan cc: pgsql-committers@lists.postgresql.org Subject: Re: pgsql: Update time zone data files to tzdata release 2024b. In-reply-to: <868637.1730328216@sss.pgh.pa.us> References: <362289.1730241666@sss.pgh.pa.us> <55A5E01C-1B0F-40F9-94EA-FEDED1575C92@dunslane.net> <595311.1730300440@sss.pgh.pa.us> <764322.1730320400@sss.pgh.pa.us> <868637.1730328216@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Wed, 30 Oct 2024 18:43:36 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <871447.1730329676.1@sss.pgh.pa.us> Date: Wed, 30 Oct 2024 19:07:56 -0400 Message-ID: <871448.1730329676@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I wrote: > ... So I'm fuzzy about the exact details of > what has happened on crake, but I'm pretty sure that it boils > down to "the dump timezone changed since 2018". Oh ... never mind, I was thinking in terms of what would happen with --use-system-timezone, but of course the buildfarm doesn't build that way. So the problem is precisely that *our* interpretation of EST5EDT changed when we adopted tzdata 2024b, and that is affecting how we dump these old timestamps. Or at least, that seems like what should be happening, but then why is only crake showing a failure? > I'm inclined to propose that we should modify the pg_upgrade test > so that it forces the comparison dumps to be taken with PGTZ=UTC, > thereby taking system-timezone changes out of the picture. Whatever the details exactly, this still seems like a good future-proof fix. I'm not quite sure where we need to make the change though --- if I edit pg_upgrade/t/002_pg_upgrade.pl, will that affect how the buildfarm tests these things, or is it different code? regards, tom lane