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 | 65b254a128385ba5256f640402952321@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: [HACKERS] make async slave to wait for lsn to be replayed (Peter Eisentraut <peter.eisentraut@enterprisedb.com>) |
Список | pgsql-hackers |
Here I made new patch of feature, discussed above. WAIT FOR procedure - waits for certain lsn on pause ========== Synopsis ========== SELECT pg_wait_lsn(‘LSN’, timeout) returns boolean Where timeout = 0, will wait infinite without timeout And if timeout = 1, then just check if lsn was replayed How to use it ========== Greg Stark wrote: > That said, I'm not a fan of the specific function names. Remember that > we have polymorphic functions so you could probably just have an > option argument: If you have any example, I will be glade to see them. Ьy searches have not been fruitful. Michael Paquier wrote: > While looking at all the patches proposed, I have noticed that all the > approaches proposed force a wakeup of the waiters in the redo loop of > the startup process for each record, before reading the next record. > It strikes me that there is some interaction with custom resource > managers here, where it is possible to poke at the waiters not for > each record, but after reading some specific records. Something > out-of-core would not be as responsive as the per-record approach, > still responsive enough that the waiters wait on input for an > acceptable amount of time, depending on the frequency of the records > generated by a primary to wake them up. Just something that popped > into my mind while looking a bit at the threads. I`ll work on this idea to have less impact on the redo system. On 2023-03-02 13:33, Peter Eisentraut wrote: > But I wonder how a client is going to get the LSN. How would all of > this be used by a client? As I wrote earlier 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. > I'm tempted to think this could be a protocol-layer facility. Every > query automatically returns the current LSN, and every query can also > send along an LSN to wait for, and the client library would just keep > track of the LSN for (what it thinks of as) the connection. So you > get some automatic serialization without having to modify your client > code. Yes it sounds very tempted. But I think community will be against it. -- Ivan Kartyshov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
Вложения
В списке pgsql-hackers по дате отправления: