Re: [Bug] Logical Replication failing if the DateStyle is different in Publisher & Subscriber - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [Bug] Logical Replication failing if the DateStyle is different in Publisher & Subscriber
Date
Msg-id 1495973.1634530627@sss.pgh.pa.us
Whole thread Raw
In response to Re: [Bug] Logical Replication failing if the DateStyle is different in Publisher & Subscriber  (Japin Li <japinli@hotmail.com>)
Responses Re: [Bug] Logical Replication failing if the DateStyle is different in Publisher & Subscriber  (Japin Li <japinli@hotmail.com>)
List pgsql-hackers
Japin Li <japinli@hotmail.com> writes:
> On Mon, 18 Oct 2021 at 11:59, Michael Paquier <michael@paquier.xyz> wrote:
>> dblink.c has something similar as of applyRemoteGucs(), except that it
>> does not do extra_float_digits.  It would be nice to avoid more
>> duplication for those things, at least on HEAD.  On the top of my
>> head, don't we have something similar for parallel workers when
>> passing down GUCs from the leader?

> Since it will be used in more than one places. IMO, we can implement it in core.
> Any thoughts?

It's not going to be the same code everywhere.  A logrep sender won't
have a need to save-and-restore the settings like postgres_fdw does,
AFAICS.  Also, now that I look at it, dblink is doing the opposite
thing of absorbing the sender's values.

It would be good I guess to have some central notion of which
variables ought to be set to what, but I'm not sure how to
mechanize that given the need for different behaviors.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Japin Li
Date:
Subject: Re: [Bug] Logical Replication failing if the DateStyle is different in Publisher & Subscriber
Next
From: Justin Pryzby
Date:
Subject: Re: prion failed with ERROR: missing chunk number 0 for toast value 14334 in pg_toast_2619