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: Jacob Champion <jacob.champion@enterprisedb.com>
Cc: Jelte Fennema-Nio <postgres@jeltef.nl>, Tatsuo Ishii <ishii@postgresql.org>, hlinnaka@iki.fi, peter@eisentraut.org, pgsql-hackers@postgresql.org
Date: 2025-06-24T15:14:37Z
Lists: pgsql-hackers 
Jacob Champion <jacob.champion@enterprisedb.com> writes:
> 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.

+1.

> Are there any reading along who want us to continue sending an
> all-zeroes CancelRequest if the server has not sent a key?

We might have to consider doing so if evidence emerges of a server
that depends on us doing that, but right now we have no such evidence.

On the whole, reporting an error seems like a better user experience
than silently sending a cancel we know won't work.  But we have to
delay the error until a cancel is actually attempted.

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