Re: protocol-level wait-for-LSN

From: Jesper Pedersen <jesper(dot)pedersen(at)comcast(dot)net>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, haoran zhang <andrewzhr9911(at)gmail(dot)com>
Subject: Re: protocol-level wait-for-LSN
Date: 2024-10-29 16:22:58
Message-ID: 71d5bd2f-504f-4bad-9594-e07439cd4330@comcast.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 10/29/24 12:03 PM, Jesper Pedersen wrote:
> On 10/28/24 12:58 PM, Heikki Linnakangas wrote:
>> I'd suggest adding a new message type for this, so that it works the
>> same with simple and extended query. Or if you just want to wait
>> without issuing any query.
>
> I agree it is a good idea to have a feature like this.
>
> However, I agree with Heikki that we should have a separate message type
> for this. There are a lot of protocol implementations outside of
> PostgreSQL/Core, and they would have to adjust based on the version
> number of Core itself if we add fields to existing message types.
>
> Maybe there should be an "Extension ('x') (F)" message that only has a
> fixed "header", and the rest of the fields are based on the "header"
> limited by the message length field - sort of free-form. The result is
> returned as a "DataRow ('D') (B)" list.
>

I understand that we need this to be "atomic" which is difficult with
the above since we can already use "Query 'Q' (F)", but we need it at
"ReadyForQuery 'Z' (B)" level.

Having a new "ReadyForQuery v2 ('z') (B)" would require changes to all
non-Core implementations as well...

Likely a protocol v4 thing.

Best regards,
Jesper

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Paul Ramsey 2024-10-29 16:23:21 Re: RFC: Extension Packaging & Lookup
Previous Message Jesper Pedersen 2024-10-29 16:03:04 Re: protocol-level wait-for-LSN