Re: [HACKERS] make async slave to wait for lsn to be replayed
От | Kartyshov Ivan |
---|---|
Тема | Re: [HACKERS] make async slave to wait for lsn to be replayed |
Дата | |
Msg-id | eb12f9b03851bb2583adab5df9579b4b@postgrespro.ru обсуждение исходный текст |
Ответы |
Re: [HACKERS] make async slave to wait for lsn to be replayed
Re: [HACKERS] make async slave to wait for lsn to be replayed |
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: