| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Japin Li <japinli(at)hotmail(dot)com> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Sadhuprasad Patro <b(dot)sadhu(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: [Bug] Logical Replication failing if the DateStyle is different in Publisher & Subscriber |
| Date: | 2021-10-18 04:17:07 |
| Message-ID: | 1495973.1634530627@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Japin Li <japinli(at)hotmail(dot)com> writes:
> On Mon, 18 Oct 2021 at 11:59, Michael Paquier <michael(at)paquier(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Justin Pryzby | 2021-10-18 04:21:28 | Re: prion failed with ERROR: missing chunk number 0 for toast value 14334 in pg_toast_2619 |
| Previous Message | Japin Li | 2021-10-18 04:13:37 | Re: [Bug] Logical Replication failing if the DateStyle is different in Publisher & Subscriber |