Re: BackendKeyData is mandatory?

On Tue, Jul 1, 2025 at 1:15 AM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
>
> Pretending that
> libpq is the "golden standard" for our protocol just seems plain wrong
> to me.

Not what I said. I'm saying that if a server implementation claims
Postgres compatibility but fails to talk to deployed versions of libpq
in practice, people will roll their eyes, even if other client
implementations work. The most widely deployed implementation tends to
be favored independently of technical quality.

> For instance libpq even supports receiving BackendKeyData many
> more times after startup, due to implementation laziness. Do we want
> to start documenting that as being part of the protocol?

It's not up to me whether we do or not. Since the protocol is
underspecified and these corner cases are untested, what really
matters is how many people depend on the underspecified behavior. (I
point to the immediately preceding thread as evidence.)

> > 2. Without a way to enforce or test this behavior, I'm not excited
> > about tying the 3.2 protocol definition to a change that we still
> > might revert for 3.0. Maybe that is the least bad way forward, but I
> > would want more committers than just me to buy into that agreement
> > first.
>
> If we want to revert the behaviour for 3.0 that would be purely
> because of some existing software somehow relying on this all zeros
> CancelRequest. If that existing software then wants to start
> supporting 3.2 (or more likely a later protocol version), then they
> would need to start sending a BackendKeyData with all zeros themselves
> first to get the same client behaviour. That seems like an easy enough
> workaround for the server implementers, and most importantly one that
> does not impact any old servers (because those won't have implemented
> 3.2).

But again: we do not enforce or test this behavior, so if the revert
happens for 3.0 later, we all have to watch like hawks to make sure
that 3.2 is not affected. I need more buy-in for that from people who
are not me.

> > > > Also, what should we do if the server sends a zero-length key?
> > >
> > > Given that that only applies to protocol 3.2,
> >
> > It applies to 3.0 too. (There is no longer any code in the client that
> > locks the length of the key to four bytes.) This applies to PG18 and
> > onwards.
>
> That seems like a bug in libpq that we do not disallow that for 3.0.

Well... okay. I'm reasoning based on what's committed.

Right now, libpq's interpretation of 3.2 is more akin to an
advertisement that it supports variable-length cancel keys from the
server -- and crucially, it now supports variable-length keys for 3.0
too. (This weirdness makes more sense when you consider that the patch
started life as a _pq_ parameter, not a version bump.)

> However, in practice even without changing that, this would still only
> apply to 3.2, because servers should not dare to send different length
> BackendKeyData for a 3.0 connection. Even if modern libpq handles this
> correctly on 3.0 connections, previous versions would still throw an
> error, and many other clients will fail too.

Personally, I think it's more likely that any new server
implementations with alternative cancellation requirements will start
to silently couple against the new 3.0 behavior. I don't believe for a
minute that third parties "would not dare" to do literally anything
that works in practice. We're not the spec police and no one is going
to ask us for permission; if we want other implementations to behave a
certain way then we have to enforce it in the code.

--Jacob