| From: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
|---|---|
| To: | Andrey Silitskiy <a(dot)silitskiy(at)postgrespro(dot)ru> |
| Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, "Takamichi Osumi (Fujitsu)" <osumi(dot)takamichi(at)fujitsu(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "sawada(dot)mshk(at)gmail(dot)com" <sawada(dot)mshk(at)gmail(dot)com>, "michael(at)paquier(dot)xyz" <michael(at)paquier(dot)xyz>, "peter(dot)eisentraut(at)enterprisedb(dot)com" <peter(dot)eisentraut(at)enterprisedb(dot)com>, "dilipbalaut(at)gmail(dot)com" <dilipbalaut(at)gmail(dot)com>, "andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de>, "amit(dot)kapila16(at)gmail(dot)com" <amit(dot)kapila16(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, Greg Sabino Mullane <htamfids(at)gmail(dot)com>, Vitaly Davydov <v(dot)davydov(at)postgrespro(dot)ru> |
| Subject: | Re: Exit walsender before confirming remote flush in logical replication |
| Date: | 2026-01-03 00:31:51 |
| Message-ID: | CAPpHfdukcCYL4dGiCOpZH6i=p-1+btindaALF5FyWNGsgNU+ow@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi, Andrey!
On Thu, Nov 27, 2025 at 12:19 PM Andrey Silitskiy
<a(dot)silitskiy(at)postgrespro(dot)ru> wrote:
> On Nov 23, 2025 at 11:46 PM Fujii Masao
> <masao(dot)fujii(at)gmail(dot)com> wrote:
> > The difference is that PGC_USERSET also allows per–replication-user
> > overrides when needed, which gives users more flexibility without
> > losing the ability to set a server-wide setting, I think.
> > ...
> > I think there are valid use cases for applying this setting to
> > physical replication as well.
> Thanks for the comments. I agree, this parameter also seems usable
> for physical replication, if you use it with caution. In this case,
> it really becomes useful to be able to configure a parameter for
> each connection. I have added these changes to my patch.
>
> Also, earlier I did not mention another difference between my patch
> and those discussed earlier. Previously, even in immediate mode,
> WalSndCaughtUp flag was checked before calling WalSndDone,
> and this made it impossible to shut down even in immediate mode
> with WalSndCaughtUp = false when the server has full output buffers.
> This does not happen in the current patch implementation. I added
> an additional test case for this situation.
Thank you for reviving this thread. I think it is reasonable to move
control over the walsender shutdown behavior to the primary server. I
see an analogy with synchronous_commit and synchronous_standby_names.
Primary decides which standbys wait and which way to wait for them.
Similarly, the primary should decide who to wait on the shutdown.
I would like to make a couple of suggestions for the patch.
1) I think it's useful to tune particular standbys/subscribers to
specify the walsender shutdown mode. It was possible in the patch by
Hayato Kuroda, and it would be a pity to lose. I suggest implementing
the walsender shutdown mode as a replication slot option.
2) Given that walsender shutdown mode would be a replication slot
option, I propose to rename GUC to default_wal_sender_shutdown_mode.
Also, given we would more likely need to wait for a flush during
streaming replication, I would suggest following modes: immediate,
wait_for_flush_streaming_only, wait_for_flush. The new intermediate
option would make walsender wait for a flush only for physical
standbys but not for logical subscribers.
What do you think?
------
Regards,
Alexander Korotkov
Supabase
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2026-01-03 00:38:30 | Re: [PATCH] Add support for SAOP in the optimizer for partial index paths |
| Previous Message | Andreas Karlsson | 2026-01-03 00:24:56 | Re: [Proposal] Generate pkg-config for server module development |