Re: [HACKERS] make async slave to wait for lsn to be replayed - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [HACKERS] make async slave to wait for lsn to be replayed
Date
Msg-id a7601ec6-01d8-4561-b81d-a6605e9b4d55@eisentraut.org
Whole thread Raw
In response to Re: [HACKERS] make async slave to wait for lsn to be replayed  (Alexander Korotkov <aekorotkov@gmail.com>)
Responses 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
List 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 by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: documentation structure
Next
From: Melih Mutlu
Date:
Subject: Re: Flushing large data immediately in pqcomm