Re: protocol-level wait-for-LSN

From: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Tatsuo Ishii <ishii(at)postgresql(dot)org>, peter(at)eisentraut(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: protocol-level wait-for-LSN
Date: 2024-10-30 14:01:27
Message-ID: CAGECzQRhRaOq4h-EC8YHgbiErBq5ries4Cii=hwhaM2tY_SDeQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 30 Oct 2024 at 12:53, Heikki Linnakangas <hlinnaka(at)iki(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Junwang Zhao 2024-10-30 14:17:18 Re: general purpose array_sort
Previous Message Jelte Fennema-Nio 2024-10-30 13:58:44 Use "protocol options" name instead of "protocol extensions" everywhere