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

On Wed, Jul 2, 2025 at 3:18 PM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
> I think you might have meant: "If libpq doesn't
> allow it, even though the spec suggets it should, then people will still
> blame the server implemantion".

Yes. Same for clients which disallow corner cases that the spec is
silent on but libpq allows.

> > 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.)
>
> Agreed. But what I was trying to say was that you need more than just
> libpq to behave in an unspecified way. You need some critical mass of
> clients to behave in a similar enough unspecified way.

Sure, but I believe very strongly in people's ability to find and
depend on nonstandard behavior in popular protocols. :) It's a
law-of-large-numbers thing.

> Sidenote: I checked just now. JDBC did send the all zeros message too
> before it added 3.2 cancel support.

Okay, wait -- JDBC was _copying_ our weird behavior? Why? Does
something depend it in the wild?

> > But again: we do not enforce or test this behavior,
>
> I'd love to have your protocol test suite to be able to add
> automated tests for this ;)

Agreed.

> > 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.
>
> Okay, but to be clear: You do agree with this approach? (assuming others
> will agree too)

At the moment, yes. (We might as well signal a protocol change with
our protocol bump. :D)

> > Well... okay. I'm reasoning based on what's committed.
>
> Attached is a v2 patchset that addresses this, as well as all the other
> changes previously discussed. I tested that the behaviour is as intended
> by modifying the PG sources locally.

I will hold off on detailed review until Heikki gives an opinion on
the design (or we get closer to the end of the month), to avoid making
busy work for you -- but I will say that I think you need to prove
that the new `failure:` case in getBackendKeyData() is safe, because I
don't think any of the other failure modes behave that way inside
pqParseInput3().

> > 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.
>
> Maybe in some years, yes. But it seems rather unlikely that people would
> start doing that now, because that would mean that old clients that
> request 3.0 would suddenly not be able to connect because they get a
> "malformed" BackendKeyData message.

Maybe. Or maybe "Our new server supports 3.0, but only with PG18
onwards for some reason. ChatGPT isn't sure why it's different. We're
super popular now."

--Jacob