Re: [HACKERS] make async slave to wait for lsn to be replayed
Peter Eisentraut <peter@eisentraut.org>
On 17.03.24 15:09, Alexander Korotkov wrote: > My current attempt was to commit minimal implementation as less > invasive as possible. A new clause for BEGIN doesn't require > additional keywords and doesn't introduce additional statements. But > yes, this is still a new qual. And, yes, Amit you're right that even > if I had committed that, there was still a high risk of further > debates and revert. I had written in [0] about my questions related to using this with connection poolers. I don't think this was addressed at all. I haven't seen any discussion about how to make this kind of facility usable in a full system. You have to manually query and send LSNs; that seems pretty cumbersome. Sure, this is part of something that could be useful, but how would an actual user with actual application code get to use this? [0]: https://www.postgresql.org/message-id/8b5b172f-0ae7-d644-8358-e2851dded43b%40enterprisedb.com
Commits
-
Ensure standby promotion point in 043_wal_replay_wait.pl
- 2520226c953c 18.0 landed
-
Minor cleanup related to pg_wal_replay_wait() procedure
- 85b98b8d5a48 18.0 landed
-
Adjust pg_wal_replay_wait() procedure behavior on promoted standby
- 867d396ccd2a 18.0 landed
-
pg_wal_replay_wait(): Fix typo in the doc
- 8036d73ae3d4 18.0 landed
-
Implement pg_wal_replay_wait() stored procedure
- 3c5db1d6b016 18.0 landed
- 06c418e163e9 17.0 landed
-
Revert: Implement pg_wal_replay_wait() stored procedure
- 772faafca1b2 17.0 landed
-
Call WaitLSNCleanup() in AbortTransaction()
- 74eaf66f988c 17.0 landed
-
Clarify what is protected by WaitLSNLock
- ee79928441e7 17.0 landed
-
Use an LWLock instead of a spinlock in waitlsn.c
- 25f42429e2ff 17.0 landed
-
Use the pairing heap instead of a flat array for LSN replay waiters
- bf1e65080629 17.0 landed
-
Minor improvements for waitlsn.c
- e37662f22158 17.0 landed
-
Make the order of the header file includes consistent
- 97d85be36544 17.0 cited