Re: [HACKERS] make async slave to wait for lsn to be replayed
От | Peter Eisentraut |
---|---|
Тема | Re: [HACKERS] make async slave to wait for lsn to be replayed |
Дата | |
Msg-id | a7601ec6-01d8-4561-b81d-a6605e9b4d55@eisentraut.org обсуждение исходный текст |
Ответ на | Re: [HACKERS] make async slave to wait for lsn to be replayed (Alexander Korotkov <aekorotkov@gmail.com>) |
Ответы |
Re: [HACKERS] make async slave to wait for lsn to be replayed
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 |
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
В списке pgsql-hackers по дате отправления: