From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: postgres_fdw fails because GMT != UTC |
Date: | 2024-04-04 09:08:32 |
Message-ID: | F9A3C95E-FA62-4040-94F4-3BA52D5CA3A7@yesql.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 4 Apr 2024, at 08:19, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Over at [1] we have a complaint of postgres_fdw failing with
> a remote-server error
>
>> ERROR: invalid value for parameter "TimeZone": "UTC"
>
> I am not quite clear on how broken an installation needs to be to
> reject "UTC" as a time zone setting, except that the breakage cannot
> be subtle. However, I notice that our code in pgtz.c and other
> places treats "GMT" as a hard-wired special case ... but not "UTC".
> I wonder if we ought to modify those places to force "UTC" down the
> same hard-wired paths. If we acted like that, this would have worked
> no matter how misconfigured the installation was.
+1. It makes little sense to support GMT like that but not UTC.
> An alternative answer could be to change postgres_fdw to send "GMT"
> not "UTC". That's ugly from a standards-compliance viewpoint, but
> it would fix this problem even with a non-updated remote server,
> and I think postgres_fdw is generally intended to work with even
> very old remote servers.
There is always a risk in accomodating broken installations that it might hide
other subtle bugs, but off the cuff that risk seems quite low in this case.
--
Daniel Gustafsson
From | Date | Subject | |
---|---|---|---|
Next Message | Etsuro Fujita | 2024-04-04 09:08:40 | Re: ExecAppendAsyncEventWait() in REL_14_STABLE can corrupt PG_exception_stack |
Previous Message | Masahiko Sawada | 2024-04-04 09:05:02 | Re: Introduce XID age and inactive timeout based replication slot invalidation |