| 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>, tgl(at)sss(dot)pgh(dot)pa(dot)us, hlinnaka(at)iki(dot)fi, peter(at)eisentraut(dot)org, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: BackendKeyData is mandatory? |
| Date: | 2025-06-24 15:07:41 |
| Message-ID: | CAOYmi+nopSksm11tOAU_+KqoXxgyGyS97rQ8RY5OxcvKOhC=DQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jun 24, 2025 at 1:36 AM Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> wrote:
> Okay, that sounds widely used enough to continue that we should
> probably change the new PG18 behaviour of PQgetCancel and
> PQcancelCreate like I suggested. Failing all psycopg2 connection
> attempts against AWS its proxy service doesn't seem like something
> we'd want to do.
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.
Are there any reading along who want us to continue sending an
all-zeroes CancelRequest if the server has not sent a key? Personally,
I don't feel a need to push for that without evidence that it's
actually used, and both RDS Proxy and Cockroach [1] seem to fall in
the "don't support cancellation at all" bucket.
Thanks!
--Jacob
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jelte Fennema-Nio | 2025-06-24 15:12:04 | Re: BackendKeyData is mandatory? |
| Previous Message | Tomas Vondra | 2025-06-24 15:04:00 | Re: pgsql: Introduce pg_shmem_allocations_numa view |