Re: BackendKeyData is mandatory? - Mailing list pgsql-hackers

On Tue, 1 Jul 2025 at 00:23, Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
> when other people say "Postgres wire-compatible",
> they're talking about us.

Many people instead are talking about JDBC (Java) or the Npgsql (C#).
These are both much better implementations of the protocol than libpq
is IMO (e.g. libpq still cannot request binary text based per column,
and it couldn't send a Close message until recently). Pretending that
libpq is the "golden standard" for our protocol just seems plain wrong
to me. 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?

> Plus, modern IETF specs are _very_ good at mentioning when problems in
> widely-deployed implementations have led to a protocol decision.
> (Calling them out by name, in the permanent RFC, would probably be
> unwise in many situations. But we don't have any reason to avoid
> calling ourselves out in our own docs.)

I think that's fair, and libpq can be used to give context about why
the protocol is defined the way it is. But it shouldn't be the
definition of the protocol itself.

> 1. I find this less useful to implementers. Implementers, I think,
> want to know what libpq is going to do in reality.

Okay, so how about we change it to this (first to sentences are the same)

Since protocol version 3.2, if the server sent no BackendKeyData, then
that means that the backend does not support canceling queries using
the CancelRequest messages. In protocol versions before 3.2 the
behaviour is undefined if the client receives no BackendKeyData.
Up until the libpq shipped in PostgreSQL 17, it would send a
CancelRequest with all zeros to 3.0 connections that did not send a
BackendKeyData message. Since the libpq shipped with PostgreSQL 18 it
does not send any CancelRequest at all for such connections anymore,
thus aligning with the behaviour for protocol 3.2. Throwing an error
as a client when not receiving BackendKeyData on a 3.0 connection is
not recommended, because certain server implementations are known not
to send it.

> 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).

> > > 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.
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.