On Tue, 1 Jul 2025 at 18:50, Jacob Champion <jacob.champion@enterprisedb.com> wrote:
>
> 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.
I think the confusion comes from the fact that I understood you to say:
"People don't care about the protocol, if libpq allows it, then it's
good enough." But now 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".
> 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. i.e. if JDBC
cannot connect to your custom postgres server because you went out of
spec, then users will start complaining to you that your server is
broken.
Sidenote: I checked just now. JDBC did send the all zeros message too
before it added 3.2 cancel support. But afaict the 3.2 support
introduced an issue where it will call castNonNull on a null pointer if
used on a server that does not send BackendKeyData. CC-ing Dave Cramer
because that sounds like a bug his employer would probably like fixed
because that would impact the RDS Proxy.
> 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 ;)
> 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)
> 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.
> 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.
> if we want other implementations to behave a
> certain way then we have to enforce it in the code.
Agreed
P.S. Heiki assigned himself to the open items I created now.
