Horton

Re: BackendKeyData is mandatory?

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: "David G. Johnston" <david.g.johnston@gmail.com>
Cc: Tatsuo Ishii <ishii@postgresql.org>, "hlinnaka@iki.fi" <hlinnaka@iki.fi>, "peter@eisentraut.org" <peter@eisentraut.org>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2025-06-19T15:29:55Z
Lists: pgsql-hackers 
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> At this point why does it matter what the docs says?

Yeah, I cannot get excited about changing this.  The current protocol
spec accurately documents what we do.  It is not incumbent on us to
document what non-Postgres implementations of this protocol could
hypothetically do --- especially when we're just guessing in a vacuum
as to whether this second-hand-reported behavior is intentional or
a bug.

There's an argument based on the ancient principle of "be conservative
in what you send and liberal in what you accept" that Pgpool ought
to survive not getting BackendKeyData, or at least not complain until
such time as it's asked to send a query cancel.  But that principle
is not about what it says in the protocol spec.

			regards, tom lane

Commits

  1. Revert unnecessary check for NULL

  2. libpq: Be strict about cancel key lengths

  3. libpq: Handle OOM by disconnecting instead of hanging or skipping msgs

  4. libpq: Complain about missing BackendKeyData later with PGgetCancel()