RE: Exit walsender before confirming remote flush in logical replication
Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>
From: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
To: 'Amit Kapila' <amit.kapila16@gmail.com>
Cc: Dilip Kumar <dilipbalaut@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2022-12-28T02:47:56Z
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
Attachments
- v3-0001-Exit-walsender-before-confirming-remote-flush-in-.patch (application/octet-stream) patch v3-0001
Dear Amit, > > Firstly I considered 2, but I thought 1 seemed to be better. > > PSA the updated patch. > > > > I think even for logical replication we should check whether there is > any pending WAL (via pq_is_send_pending()) to be sent. Otherwise, what > is the point to send the done message? Also, the caller of > WalSndDone() already has that check which is another reason why I > can't see why you didn't have the same check in function WalSndDone(). I did not have strong opinion around here. Fixed. > BTW, even after fixing this, I think logical replication will behave > differently when due to some reason (like time-delayed replication) > send buffer gets full and walsender is not able to send data. I think > this will be less of an issue with physical replication because there > is a separate walreceiver process to flush the WAL which doesn't wait > but the same is not true for logical replication. Do you have any > thoughts on this matter? Yes, it may happen even if this work is done. And your analysis is correct that the receive buffer is rarely full in physical replication because walreceiver immediately flush WALs. I think this is an architectural problem. Maybe we have assumed that the decoded WALs are consumed in as short time. I do not have good idea, but one approach is introducing a new process logical-walreceiver. It will record the decoded WALs to the persistent storage and workers consume and then remove them. It may have huge impact for other features and should not be accepted... Best Regards, Hayato Kuroda FUJITSU LIMITED