On 2017-09-19 13:15:28 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2017-09-19 13:00:33 -0400, Robert Haas wrote: > >> You mean, in the postmaster? > > > Yes. We try to avoid touch shmem there, but it's not like we're > > succeeding fully. See e.g. the pgstat_get_crashed_backend_activity() > > calls (which do rely on shmem being ok to some extent), pmsignal, > > BackgroundWorkerStateChange(), ... > > Well, the point is to avoid touching data structures that could be > corrupted enough to confuse the postmaster. I don't have any problem with > adding some more functionality to pmsignal, say.
Given that we're ok with reading pgstat shared memory entries, I think adding a carefully coded variant of SendProcSignal() should be doable in a safe manner. Something roughly like int PostmasterSendProcSignal(pid_t pid, ProcSignalReason reason) { volatile ProcSignalSlot *slot; /* * As this is running in postmaster, be careful not to dereference * any pointers from shared memory that could be corrupted, and to * not to throw errors. */ for (i = 0; i < NumProcSignalSlots; i++) { slot = &ProcSignalSlots[i]; if (slot->pss_pid == pid) { /* * The note about race conditions in SendProcSignal applies * here, too */ /* Atomically set the proper flag */ slot->pss_signalFlags[reason] = true; /* Send signal */ return kill(pid, SIGUSR1); } } errno = ESRCH; return -1; } As all the memory offsets are computed based on postmaster process-local variables, this should be safe. I'd rather like to avoid a copy of the procsignal infrastructure if we don't need it... Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers