database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-08-17 01:02:17 +03:00
Code Activity

Clear MyProc and MyProcSignalState before they become invalid.

Browse Source 
Evidence from buildfarm member crake suggests that the new test_shm_mq
module is routinely crashing the server due to the arrival of a SIGUSR1
after the shared memory segment has been unmapped.  Although processes
using the new dynamic background worker facilities are more likely to
receive a SIGUSR1 around this time, the problem is also possible on older
branches, so I'm back-patching the parts of this change that apply to
older branches as far as they apply.

It's already generally the case that code checks whether these pointers
are NULL before deferencing them, so the important thing is mostly to
make sure that they do get set to NULL before they become invalid.  But
in master, there's one case in procsignal_sigusr1_handler that lacks a
NULL guard, so add that.

Patch by me; review by Tom Lane.
This commit is contained in:
Robert Haas
2014-01-31 21:31:08 -05:00
parent 637fab6e57
commit d1981719ad
2 changed files with 33 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
src/backend/storage/ipc/procsignal.c
View File

@@ -149,6 +149,13 @@ CleanupProcSignalState(int status, Datum arg)
slot = &ProcSignalSlots[pss_idx - 1];
Assert(slot == MyProcSignalSlot);
/*
* Clear MyProcSignalSlot, so that a SIGUSR1 received after this point
* won't try to access it after it's no longer ours (and perhaps even
* after we've unmapped the shared memory segment).
*/
MyProcSignalSlot = NULL;
/* sanity check */
if (slot->pss_pid != MyProcPid)
{
@@ -285,7 +292,7 @@ procsignal_sigusr1_handler(SIGNAL_ARGS)
if (CheckProcSignal(PROCSIG_RECOVERY_CONFLICT_BUFFERPIN))
RecoveryConflictInterrupt(PROCSIG_RECOVERY_CONFLICT_BUFFERPIN);
if (set_latch_on_sigusr1)
if (set_latch_on_sigusr1 && MyProc != NULL)
SetLatch(&MyProc->procLatch);
latch_sigusr1_handler();