Horton

Re: BackendKeyData is mandatory?

Jacob Champion <jacob.champion@enterprisedb.com>

View thread View on postgr.es
From: Jacob Champion <jacob.champion@enterprisedb.com>
To: Jelte Fennema-Nio <postgres@jeltef.nl>
Cc: Tatsuo Ishii <ishii@postgresql.org>, tgl@sss.pgh.pa.us, hlinnaka@iki.fi, peter@eisentraut.org, pgsql-hackers@postgresql.org
Date: 2025-06-24T15:07:41Z
Lists: pgsql-hackers 
On Tue, Jun 24, 2025 at 1:36 AM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
> Okay, that sounds widely used enough to continue that we should
> probably change the new PG18 behaviour of PQgetCancel and
> PQcancelCreate like I suggested. Failing all psycopg2 connection
> attempts against AWS its proxy service doesn't seem like something
> we'd want to do.

So that's
1) return an (empty) cancellation object even if the server has not
sent a key, and
2) error out when trying to cancel with an empty object?

That sounds reasonable to me.

Are there any reading along who want us to continue sending an
all-zeroes CancelRequest if the server has not sent a key? Personally,
I don't feel a need to push for that without evidence that it's
actually used, and both RDS Proxy and Cockroach [1] seem to fall in
the "don't support cancellation at all" bucket.

Thanks!
--Jacob

[1] https://github.com/cockroachdb/cockroach/issues/32973

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