Re: [HACKERS] make async slave to wait for lsn to be replayed
Ivan Kartyshov <i.kartyshov@postgrespro.ru>
Attachments
- wait_after_within_v1.patch (text/x-diff) patch v1
- wait_classic_v1.patch (text/x-diff) patch v1
- wait_proc_v1.patch (text/x-diff) patch v1
Intro========== The main purpose of the feature is to achieve read-your-writes-consistency, while using async replica for reads and primary for writes. In that case lsn of last modification is stored inside application. We cannot store this lsn inside database, since reads are distributed across all replicas and primary. https://www.postgresql.org/message-id/195e2d07ead315b1620f1a053313f490%40postgrespro.ru Suggestions ========== Lots of proposals were made how this feature may look like. I aggregate them into the following four types. 1) Classic (wait_classic_v1.patch) https://www.postgresql.org/message-id/3cc883048264c2e9af022033925ff8db%40postgrespro.ru ========== advantages: multiple events, standalone WAIT disadvantages: new words in grammar WAIT FOR [ANY | ALL] event [, ...] BEGIN [ WORK | TRANSACTION ] [ transaction_mode [, ...] ] [ WAIT FOR [ANY | ALL] event [, ...]] where event is one of: LSN value TIMEOUT number_of_milliseconds timestamp 2) After style: Kyotaro and Freund (wait_after_within_v1.patch) https://www.postgresql.org/message-id/d3ff2e363af60b345f82396992595a03%40postgrespro.ru ========== advantages: no new words in grammar, standalone AFTER disadvantages: a little harder to understand AFTER lsn_event [ WITHIN delay_milliseconds ] [, ...] BEGIN [ WORK | TRANSACTION ] [ transaction_mode [, ...] ] [ AFTER lsn_event [ WITHIN delay_milliseconds ]] START [ WORK | TRANSACTION ] [ transaction_mode [, ...] ] [ AFTER lsn_event [ WITHIN delay_milliseconds ]] 3) Procedure style: Tom Lane and Kyotaro (wait_proc_v1.patch) https://www.postgresql.org/message-id/27171.1586439221%40sss.pgh.pa.us https://www.postgresql.org/message-id/20210121.173009.235021120161403875.horikyota.ntt%40gmail.com ========== advantages: no new words in grammar,like it made in pg_last_wal_replay_lsn, no snapshots need disadvantages: a little harder to remember names SELECT pg_waitlsn(‘LSN’, timeout); SELECT pg_waitlsn_infinite(‘LSN’); SELECT pg_waitlsn_no_wait(‘LSN’); 4) Brackets style: Kondratov https://www.postgresql.org/message-id/a8bff0350a27e0a87a6eaf0905d6737f%40postgrespro.ru ========== advantages: only one new word in grammar,like it made in VACUUM and REINDEX, ability to extend parameters without grammar fixes disadvantages: WAIT (LSN '16/B374D848', TIMEOUT 100); BEGIN WAIT (LSN '16/B374D848' [, etc_options]); ... COMMIT; Consequence ========== Below I provide the implementation of patches for the first three types. I propose to discuss this feature again/ Regards -- Ivan Kartyshov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
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