| From: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
|---|---|
| To: | Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> |
| Cc: | Tatsuo Ishii <ishii(at)postgresql(dot)org>, hlinnaka(at)iki(dot)fi, peter(at)eisentraut(dot)org, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: BackendKeyData is mandatory? |
| Date: | 2025-06-23 16:02:00 |
| Message-ID: | CAOYmi+mt2JvjmhVJs=PgKLruZsypskmiECOUCrvV4QgjCWRhCA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jun 19, 2025 at 5:12 AM Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> wrote:
> 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.
If anyone today is relying on "backend-key-less" connection, this is
potentially a breaking change. For example, psycopg2 now complains:
psycopg2.OperationalError: can't get cancellation key
whereas before, it would be able to connect, and sending a cancel
would do something. (Whether or not that "something" was useful was up
to the server implementation, I guess.)
--Jacob
| From | Date | Subject | |
|---|---|---|---|
| Next Message | jian he | 2025-06-23 16:11:27 | Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them |
| Previous Message | Nathan Bossart | 2025-06-23 15:59:51 | Re: problems with toast.* reloptions |