| From: | Ronan Dunklau <ronan(at)dunklau(dot)fr> |
|---|---|
| To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
| Cc: | Andrey Silitskiy <a(dot)silitskiy(at)postgrespro(dot)ru>, Vitaly Davydov <v(dot)davydov(at)postgrespro(dot)ru>, "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>, Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
| Subject: | Re: Exit walsender before confirming remote flush in logical replication |
| Date: | 2026-01-28 08:27:28 |
| Message-ID: | xf9b6kmx0DFSMe9zJ3hP-kxRMeOhOMwf7v914ctQ_YtPEVLlqCFkbrrw924XLR4LJynEtBX7omSa5taFyK-uoTPeWwusZiBXRYQholbUjhc=@dunklau.fr |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Monday, January 26th, 2026 at 15:08, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> Regarding the GUC name, wal_sender_shutdown seems simple and sufficient to me.
> This isn't a blocker, so I'm fine with the current name for now and
> revisiting it later if needed.
Are we considering other approaches to this ? Having the behavior be either "wait indefinitely" or "terminate immediately" is a bit coarse I think: a timeout for the wait (maybe named wal_sender_stop_timeout ?) would allow for the same usage as this patch provides (set it to -1 for indefinite wait, 0 for immediate shutdown, or any positive value to give a chance to the walsender to catch up before we terminate it forcibly).
The problem we have as of now is when the walreceiver is indeed connected and not reaching wal_sender_timeout as it's still processing: a distinct timeout would alleviate that.
Regards,
--
Ronan Dunklau
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chao Li | 2026-01-28 08:38:08 | psql: make %P prompt option consistent when not connected |
| Previous Message | ji xu | 2026-01-28 08:10:49 | Correction to comment of brin_range_deserialize |