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

From Japin Li
Subject Re: [Bug] Logical Replication failing if the DateStyle is different in Publisher & Subscriber
Date
Msg-id MEYP282MB1669273DBA15D084E2E1F80AB6BC9@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM
Whole thread Raw
In response to Re: [Bug] Logical Replication failing if the DateStyle is different in Publisher & Subscriber  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, 18 Oct 2021 at 12:17, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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,

Thanks for your explanation.  Yeah, we do not need reset the settings in
logical replication.

> AFAICS.  Also, now that I look at it, dblink is doing the opposite
> thing of absorbing the sender's values.
>

Sorry I misunderstand. You are right, the dblink applies the remote
server's settings to local server.


Attached v3 patch modify the settings on sender as you suggest.

-- 
Regrads,
Japin Li.
ChengDu WenWu Information Technology Co.,Ltd.


Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: BUG #17220: ALTER INDEX ALTER COLUMN SET (..) with an optionless opclass makes index and table unusable
Next
From: Japin Li
Date:
Subject: Re: [Bug] Logical Replication failing if the DateStyle is different in Publisher & Subscriber