Re: BackendKeyData is mandatory?

From: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
To: Tatsuo Ishii <ishii(at)postgresql(dot)org>
Cc: hlinnaka(at)iki(dot)fi, peter(at)eisentraut(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: BackendKeyData is mandatory?
Date: 2025-06-19 12:12:23
Message-ID: CAGECzQRRAK2QgOKyb6JTySCMia_-gkkM6O2Xk+u6FCcs3sNd1w@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 19 Jun 2025 at 13:51, Tatsuo Ishii <ishii(at)postgresql(dot)org> wrote:
> > FWIW my reading of the protocol docs is that BackendKeyData is
> > optional.
>
> If majority of developers think so, do we want to update the protocol
> docs? For me the docs is not clear enough.

I think the docs currently definitely suggests that BackendKeyData
will always be sent (emphasis mine):

> After having received AuthenticationOk, the frontend must wait for further messages from the server. In this phase a backend process is being started, and the frontend is just an interested bystander. It is still possible for the startup attempt to fail (ErrorResponse) or the server to decline support for the requested minor protocol version (NegotiateProtocolVersion), *but in the normal case the backend will send some ParameterStatus messages, BackendKeyData, and finally ReadyForQuery.*

I'd be surprised if many clients handle it correctly if it is not
sent. Looking quickly at the code for pgbouncer and libpq for PG17
(and lower) they definitely don't. They won't throw an error, but
instead of doing nothing when the user tries to cancel a query they
will instead send a cancel message with all zeros to the server. Since
PG18 libpq handles a cancel call nicely as a no-op, when no cancel key
was received.

I agree that it would be good to explicitly call out that the server
not sending BackendKeyData is an option if we don't want the server to
require sending this message.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2025-06-19 12:24:15 Re: minimum Meson version
Previous Message Peter Eisentraut 2025-06-19 12:10:41 Re: pg_dump/pg_dumpall help synopses and terminology