From: | Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, Tatsuo Ishii <ishii(at)postgresql(dot)org>, tgl(at)sss(dot)pgh(dot)pa(dot)us, peter(at)eisentraut(dot)org, pgsql-hackers(at)postgresql(dot)org, Dave Cramer <davecramer(at)gmail(dot)com> |
Subject: | Re: BackendKeyData is mandatory? |
Date: | 2025-07-29 21:20:24 |
Message-ID: | CAGECzQT-NJX8b1ENJnErkZEmc9y5m6VgzVaLmH4gFutd0W6KbA@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 29 Jul 2025 at 22:42, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> I'm not quite sold on the change to PQcancelCreate(). The current
> behavior seems nicer: if cancellation is not available because the
> server didn't send a cancellation key, PQcancelCreate() returns a
> (cancel) connection object that's in a failed state with an error
> message explaining what's wrong. The client can choose to continue
> without cancellation capability, or bail out.
>
> Are there any known drivers that require the change to PQcancelCreate()?
I scoured github search[1] and it seems that (sadly) the only two
libraries (on github) that actually use PQcancelCreate are psycopg3
and ruby-pg. Both of those only create the object when they actually
want to cancel something (not when they use it). So I agree that the
change in bahaviour in PG18 for this function seems fine, and probably
is desirable. So feel free to commit my previous patch without the
changes to PQcancelCreate.
From | Date | Subject | |
---|---|---|---|
Next Message | Sami Imseih | 2025-07-29 22:08:09 | Re: track generic and custom plans in pg_stat_statements |
Previous Message | Heikki Linnakangas | 2025-07-29 20:41:57 | Re: BackendKeyData is mandatory? |