| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
| Cc: | Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, 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-24 15:14:37 |
| Message-ID: | 949118.1750778077@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> writes:
> 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.
+1.
> Are there any reading along who want us to continue sending an
> all-zeroes CancelRequest if the server has not sent a key?
We might have to consider doing so if evidence emerges of a server
that depends on us doing that, but right now we have no such evidence.
On the whole, reporting an error seems like a better user experience
than silently sending a cancel we know won't work. But we have to
delay the error until a cancel is actually attempted.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Borisov | 2025-06-24 15:20:39 | Re: Improve the performance of Unicode Normalization Forms. |
| Previous Message | Melanie Plageman | 2025-06-24 15:12:45 | Re: Simplify VM counters in vacuum code |