On 19/06/2025 13:03, Tatsuo Ishii wrote:
I think that's fine, if the server does not want to support query
cancellation. The current protocol description certainly does not
support the idea that it is a hard error *not* to send BackendKeyData.
Isn't it scary if the server does not allow a query cancel? For
example, if the server charge you per query duration and if you
accidentally send a long running query, the only escape exit is the
query cancellation.
Or disconnect. Or pg_cancel_backend().
You can also easily have a stray psql session where the user has gone
out for lunch. Or an application that doesn't have a timeout. Many other
scenarios like that.
It's also worth thinking about the new protocol 3.2 longer key data.
A paranoid server might choose to send key data only if protocol >=3.2
is chosen and not if a lower, notionally less secure version is
chosen.
I would say the server does wrong a decision. I think even if the key
is not long, it's still useful than nothing.
I tend to agree, but people have different priorities. It's also
reasonable that you'd want to only support long cancellation keys. Or
maybe you have a proxy that doesn't implement query cancellation, or
only supports it with long keys because it embeds routing information in
the key, or something like that.
FWIW my reading of the protocol docs is that BackendKeyData is optional.
If I was writing a client today, I would accept it missing. But of
course all PostgreSQL versions today do send it, and I wouldn't be
surprised if there are clients out there that get confused if they don't
see it.
- Heikki
