Move cancel key generation to after forking the backend
authorHeikki Linnakangas <heikki.linnakangas@iki.fi>
Mon, 29 Jul 2024 12:37:48 +0000 (15:37 +0300)
committerHeikki Linnakangas <heikki.linnakangas@iki.fi>
Mon, 29 Jul 2024 12:37:48 +0000 (15:37 +0300)
commit9d9b9d46f3c509c722ebbf2a1e7dc6296a6c711d
tree450cf30fdaca9dd1b5336179f2bb590e397fb9f0
parent19de089cdc23373e2f36916017a1e23e8ff4c2f8
Move cancel key generation to after forking the backend

Move responsibility of generating the cancel key to the backend
process. The cancel key is now generated after forking, and the
backend advertises it in the ProcSignal array. When a cancel request
arrives, the backend handling it scans the ProcSignal array to find
the target pid and cancel key. This is similar to how this previously
worked in the EXEC_BACKEND case with the ShmemBackendArray, just
reusing the ProcSignal array.

One notable change is that we no longer generate cancellation keys for
non-backend processes. We generated them before just to prevent a
malicious user from canceling them; the keys for non-backend processes
were never actually given to anyone. There is now an explicit flag
indicating whether a process has a valid key or not.

I wrote this originally in preparation for supporting longer cancel
keys, but it's a nice cleanup on its own.

Reviewed-by: Jelte Fennema-Nio
Discussion: https://www.postgresql.org/message-id/508d0505-8b7a-4864-a681-e7e5edfe32aa@iki.fi
12 files changed:
src/backend/postmaster/auxprocess.c
src/backend/postmaster/launch_backend.c
src/backend/postmaster/postmaster.c
src/backend/storage/ipc/ipci.c
src/backend/storage/ipc/procsignal.c
src/backend/tcop/backend_startup.c
src/backend/tcop/postgres.c
src/backend/utils/init/globals.c
src/backend/utils/init/postinit.c
src/include/miscadmin.h
src/include/postmaster/postmaster.h
src/include/storage/procsignal.h