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 1rskKH-008zp1-Vz for pgsql-general@arkaria.postgresql.org; Fri, 05 Apr 2024 14:13:54 +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 1rskKH-00GnDT-59 for pgsql-general@arkaria.postgresql.org; Fri, 05 Apr 2024 14:13:53 +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 1rskKG-00GnDL-Qi for pgsql-general@lists.postgresql.org; Fri, 05 Apr 2024 14:13:52 +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 1rskKE-000nYv-2A for pgsql-general@postgresql.org; Fri, 05 Apr 2024 14:13:52 +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 435EDcoR1273543; Fri, 5 Apr 2024 10:13:39 -0400 From: Tom Lane To: Adnan Dautovic cc: Adrian Klaver , pgsql-general@postgresql.org Subject: Re: Failure of postgres_fdw because of TimeZone setting In-reply-to: <0849E257-0A15-4C2F-A41B-7E0E4B716CAE@mailbox.org> References: <5DF49366-10D1-42A4-99BF-F9A7DC3AB0F4@mailbox.org> <0849E257-0A15-4C2F-A41B-7E0E4B716CAE@mailbox.org> Comments: In-reply-to Adnan Dautovic message dated "Fri, 05 Apr 2024 11:39:04 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1273541.1712326418.1@sss.pgh.pa.us> Date: Fri, 05 Apr 2024 10:13:38 -0400 Message-ID: <1273542.1712326418@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Adnan Dautovic writes: > However, this lead me to [2] and I find the output very > interesting: > SELECT * FROM pg_timezone_names ORDER BY name; >> "name" "abbrev" "utc_offset" "is_dst" >> "Turkey" "+03" "03:00:00" false >> "UCT" "UCT" "00:00:00" false >> "Universal" "UTC" "00:00:00" false >> "W-SU" "MSK" "03:00:00" false Wow. To clarify, is that the *whole* result? But even if you just excerpted it, you're clearly missing a lot of entries. Per your other answer, the remote DB doesn't seem to have been built with --with-system-tzdata, so it must be relying on a Postgres-private copy of the tzdb data set, and evidently a fair number of entries in that have gone missing. Postgres itself would never modify that data after installation, so we're left to speculate about filesystem corruption or somebody's odd desire to remove "unnecessary" files. Out of curiosity, does SET timezone to 'GMT'; work? regards, tom lane