Re: protocol-level wait-for-LSN

Hi,

On 10/30/24 3:49 PM, Jelte Fennema-Nio wrote:
> On Wed, 30 Oct 2024 at 19:04, Jesper Pedersen
> <jesper(dot)pedersen(at)comcast(dot)net> wrote:
>> Having LSN would be nice, but to break all existing implementations, no.
>> Having to specify with startup parameters how a core message format
>> looks like sounds like a bad idea to me,
>
> It would really help if you would explain why you think it's a bad
> idea to use a startup parameter for that, instead of simply stating
> that you think it needs a major protocol version bump.
>
> The point of enabling it through a startup parameter (aka protocol
> option) is exactly so it will not break any existing implementations.
> If clients request the protocol option (which as the name suggests is
> optional), then they are expected to be able to parse it. If they
> don't, then they will get the old message format. So no existing
> implementation will be broken. If some middleware/proxy gets a request
> for a startup option it does not support it can advertise that to the
> client using the NegotiateProtocolVersion message. Allowing the client
> to continue in a mode where the option is not enabled.
>
> So, not bumping the major protocol version and enabling this feature
> through a protocol option actually causes less breakage in practice.
>

Yes, but it opens up for everybody changing all message formats by
startup parameters.

And, it will be confusing to clean-room implementations: When you have
this startup parameter then you get these message formats, when you have
this startup parameter then you get these message formats -- and what
about combinations ? Like Tatsuo-san stated up-thread.

You are also assuming that all PostgreSQL protocol implementations uses
the Length (Int32) field very strict - so when one developer adds the
startup parameter, but doesn't change the underlying implementation
everything will break.

The protocol format must be 100% clear and well-documented in all cases.

> Also regarding the wishlist. I think it's much more likely for any of
> those to happen in a minor version bump and/or protocol option than it
> is that we'll bump the major protocol version.
>

I agree that protocol v4 is likely far out unless somebody want to
coordinate the work needed.

> P.S. Like I said in another email on this thread: I think for this
> specific case I'd also prefer a separate new message, because that
> makes it easier to filter that message out when received by PgBouncer.
> But I'd still like to understand your viewpoint better on this,
> because adding fields to existing message types is definitely one of
> the types of changes that I personally think would be fine for some
> protocol changes.
>

If this door is open then it has to very clear how multiple startup
parameters are handled at the protocol level, and that is a much bigger
fish because what happens if extensions add startup parameters as well.

Adding a new message could be the way forward, but that opens the door
for the wish-lists for v4.

Best regards,
Jesper