Re: Exit walsender before confirming remote flush in logical replication
Andrey Silitskiy <a.silitskiy@postgrespro.ru>
From: Andrey Silitskiy <a.silitskiy@postgrespro.ru>
To: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
Cc: Fujii Masao <masao.fujii@gmail.com>,
"Takamichi Osumi (Fujitsu)" <osumi.takamichi@fujitsu.com>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
"sawada.mshk@gmail.com" <sawada.mshk@gmail.com>,
"michael@paquier.xyz" <michael@paquier.xyz>,
"peter.eisentraut@enterprisedb.com" <peter.eisentraut@enterprisedb.com>,
"dilipbalaut@gmail.com" <dilipbalaut@gmail.com>,
"andres@anarazel.de" <andres@anarazel.de>,
"amit.kapila16@gmail.com" <amit.kapila16@gmail.com>,
Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
Peter Smith <smithpb2250@gmail.com>, Greg Sabino Mullane
<htamfids@gmail.com>, Vitaly Davydov <v.davydov@postgrespro.ru>,
Alexander Korotkov <aekorotkov@gmail.com>
Date: 2026-01-17T15:46:24Z
Lists: pgsql-hackers
Attachments
- v3-0001-Introduce-a-new-GUC-wal_sender_shutdown_mode.patch (text/x-patch) patch v3-0001
Dear Hayato, Thanks for your comments! Updated the patch. On Jan 15, 2026 at 11:48 AM Hayato Kuroda <kuroda(dot)hayato(at)fujitsu(dot)com> wrote: > I think we can just use stop() because it internally runs `pg_ctl stop` > and that command waits till the wait is finished by default. I feel it > is dangerous to determine timeout to 5sec because the test can work on > very poor environment. ok_with_timeout was added because it allows to output a more reasonable log in case of a problem from this thread: "Failed test 'Successful fast shutdown of server with empty output buffers (timed out after 5 seconds)'" instead of the usual "pg_ctl stop failed". But now I noticed that the standard timeout is triggered earlier, and when setting a timeout in this function greater than the standard PGCTLTIMEOUT, only "pg_ctl stop failed" will be written. Perhaps it is reasonable to remove these functions. > Also, not sure, how can we ensure the buffer is full here? Also, even > if we have the way to check, the size may be quite platform depending. > I think it may be better to test both streaming and logical replication > instead of testing empty/full output buffer. Thought? Initially, a second test case was added to show that previous patches did not fix the problem of hanging in case of full buffers. I agree that it may depend on the platform, but I can't think of a way to guarantee this, even though the test case seems useful for checking the new mode. Test contains only the case of logical replication, since so far I'm not sure how to reproduce guaranteed flush delay on a physical replica in the test. Any ideas? Regards, Andrey Silitskiy
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Avoid blocking indefinitely while finishing walsender shutdown
- c0b24b32b0d3 19 (unreleased) landed
-
Add wal_sender_shutdown_timeout GUC to limit shutdown wait for replication
- a8f45dee9176 19 (unreleased) landed
-
pg_upgrade: Add --copy option
- 746915c68669 16.0 cited
-
Prevent possibility of panics during shutdown checkpoint.
- c6c333436491 10.0 cited
-
Support clean switchover.
- 985bd7d49726 9.4.0 cited