Skip to content

Commit 613f647

Browse files
committed
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
1 parent 4300d8b commit 613f647

File tree

1 file changed

+5
-1
lines changed

1 file changed

+5
-1
lines changed

src/backend/storage/ipc/procsignal.c

Lines changed: 5 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -728,7 +728,11 @@ procsignal_sigusr1_handler(SIGNAL_ARGS)
728728
void
729729
SendCancelRequest(int backendPID, const uint8 *cancel_key, int cancel_key_len)
730730
{
731-
Assert(backendPID != 0);
731+
if (backendPID == 0)
732+
{
733+
ereport(LOG, (errmsg("invalid cancel request with PID 0")));
734+
return;
735+
}
732736

733737
/*
734738
* See if we have a matching backend. Reading the pss_pid and

0 commit comments

Comments
 (0)