From: | Jesper Pedersen <jesper(dot)pedersen(at)comcast(dot)net> |
---|---|
To: | Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> |
Cc: | Ants Aasma <ants(dot)aasma(at)cybertec(dot)at>, Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: protocol-level wait-for-LSN |
Date: | 2024-10-31 12:59:01 |
Message-ID: | eac06961-edda-488e-927d-c153095e396d@comcast.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2024-10-31 13:08:58 | Re: Wrong result when enable_partitionwise_join is on if collation of PartitionKey and Column is different. |
Previous Message | Daniel Gustafsson | 2024-10-31 12:27:39 | Re: IPC::Run::time[r|out] vs our TAP tests |