Horton

Re: Exit walsender before confirming remote flush in logical replication

Andrey Silitskiy <a.silitskiy@postgrespro.ru>

View thread
From: Andrey Silitskiy <a.silitskiy@postgrespro.ru>
To: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
Cc: "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>
Date: 2025-11-18T10:32:01Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add wal_sender_shutdown_timeout GUC to limit shutdown wait for replication

  2. pg_upgrade: Add --copy option

  3. Prevent possibility of panics during shutdown checkpoint.

  4. Support clean switchover.

Attachments

Dear pgsql-hackers,

I am also interested in solving this problem, so I suggest a patch which
is based on Hayato's work shared earlier.

The problem we are solving is that the logical walsender processes currently
do not allow postgres to shut down until receiver side confirms the flush of
all data. In case of logical replication, this is not necessary. This 
can lead
to an undesirable shutdown delay if, for example, apply worker is 
waiting for
any locks to be released.

I agree with the opinion that the default behavior of the system should 
not be
changed, as some clients may rely on the current behavior. But instead of
the START_REPLICATION parameter I propose a GUC parameter on the sender that
controls the walsender shutdown mode for all logical walsenders.the First,
the START_REPLICATION parameter places responsibility for choosing the 
sender’s
shutdown semantics on the receiver side. Second, per-subscriber settings 
do not
solve the problematic operational case where many walsenders exist: if 
even one
of N walsender processes remains configured non-immediate, the publisher can
still be blocked. In other words, setting immediate for most subscribers but
missing one does not fix the global inability to shut down.

I also attach a tap test that reproduces the apply-worker's waiting for the
release of lock and the successful shutdown of publisher in immediate 
walsender
shutdown mode.

Best Regards,
Andrey