Re: protocol-level wait-for-LSN - Mailing list pgsql-hackers

From Jelte Fennema-Nio
Subject Re: protocol-level wait-for-LSN
Date
Msg-id CAGECzQRhRaOq4h-EC8YHgbiErBq5ries4Cii=hwhaM2tY_SDeQ@mail.gmail.com
Whole thread Raw
In response to Re: protocol-level wait-for-LSN  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: protocol-level wait-for-LSN
List pgsql-hackers
On Wed, 30 Oct 2024 at 12:53, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> We might have made a mistake by calling this mechanism "protocol
> extensions", because it makes people think of user-defined extensions.

I think this is a real problem, that's probably worth fixing. I
created a separate thread to address this[1]

> So yes, each protocol extension needs to know about all the other
> protocol extensions that it can be used with. In practice we'll avoid
> doing crazy stuff so that the protocol extensions are orthogonal

Just as an example, let's say we add a server-side query time to the
protocol (which honestly seems like a pretty useful feature). So that
ReadyForQuery now returns the query time if the query_time protocol.
For clients it isn't difficult at all to support any combination of
query_time & wait_for_lsn options. As long as we define that the
wait_for_lsn field is before the query_time field if both exist, then
two simple if statements like this would do the trick:

if (wait_for_lsn_enabled) {
    // interpret next field as LSN
}
if (query_time_enabled) {
    // interpret next field as query time
}

[1]: https://www.postgresql.org/message-id/CAGECzQQoc%2BV94TrF-5cMikCMaf-uUnU52euwSCtQBeDYqXnXyA%40mail.gmail.com



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: AIO writes vs hint bits vs checksums
Next
From: Junwang Zhao
Date:
Subject: Re: general purpose array_sort