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  (Kartyshov Ivan <i.kartyshov@postgrespro.ru>)
Re: [HACKERS] make async slave to wait for lsn to be replayed  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Re: [HACKERS] make async slave to wait for lsn to be replayed  (Alexander Korotkov <aekorotkov@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: documentation structure
Следующее
От: Melih Mutlu
Дата:
Сообщение: Re: Flushing large data immediately in pqcomm