Re: Exit walsender before confirming remote flush in logical replication
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: sawada.mshk@gmail.com, kuroda.hayato@fujitsu.com, andres@anarazel.de, michael@paquier.xyz, peter.eisentraut@enterprisedb.com,
dilipbalaut@gmail.com, pgsql-hackers@postgresql.org
Date: 2023-02-02T05:53:30Z
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 →
-
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
On Thu, Feb 2, 2023 at 10:04 AM Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote: > > At Wed, 1 Feb 2023 14:58:14 +0530, Amit Kapila <amit.kapila16@gmail.com> wrote in > > On Wed, Feb 1, 2023 at 2:09 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > > > > > Otherwise, we will end up terminating > > > the WAL stream without the done message. Which will lead to an error > > > message "ERROR: could not receive data from WAL stream: server closed > > > the connection unexpectedly" on the subscriber even at a clean > > > shutdown. > > > > > > > But will that be a problem? As per docs of shutdown [1] ( “Smart” mode > > disallows new connections, then waits for all existing clients to > > disconnect. If the server is in hot standby, recovery and streaming > > replication will be terminated once all clients have disconnected.), > > there is no such guarantee. I see that it is required for the > > switchover in physical replication to ensure that all the WAL is sent > > and replicated but we don't need that for logical replication. > > +1 > > Since publisher is not aware of apply-delay (by this patch), as a > matter of fact publisher seems gone before sending EOS in that > case. The error message is correctly describing that situation. > This can happen even without apply-delay patch. For example, when apply process is waiting on some lock. -- With Regards, Amit Kapila.