| From: | Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)fi> |
|---|---|
| To: | pgsql-committers(at)lists(dot)postgresql(dot)org |
| Subject: | pgsql: Handle cancel requests with PID 0 gracefully |
| Date: | 2025-07-29 21:51:48 |
| Message-ID: | E1ugsEd-001NGB-2U@gemulon.postgresql.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers |
Handle cancel requests with PID 0 gracefully
If the client sent a query cancel request with backend PID 0, it
tripped an assertion. With assertions disabled, you got this in the
log instead:
LOG: invalid cancel request with PID 0
LOG: wrong key in cancel request for process 0
Query cancellations don't even require authentication, so we better
tolerate bogus requests. Fix by turning the assertion into a regular
runtime check.
Spotted while testing libpq behavior with a modified server that
didn't send BackendKeyData to the client.
Backpatch-through: 18
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/613f64712257d4b94e068e77fb0593e0a71d8df1
Modified Files
--------------
src/backend/storage/ipc/procsignal.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2025-07-30 02:27:27 | pgsql: doc PG 18 relnotes: update to current |
| Previous Message | Tom Lane | 2025-07-29 19:18:03 | pgsql: Don't put library-supplied -L/-I switches before user-supplied o |