Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> Thank you. Looks good to me, committed with minor changes.
I don't think this patch is anywhere near ready to apply. In the first
place, touching the PGPROC like that without any lock seems completely
unsafe --- among other things, you're relying on an undocumented
assumption that the space occupied by a PGPROC struct will never be
recycled for use as anything else. It might be all right for the
limited purposes at the moment, but if you are advertising this as a
general purpose signal multiplexer then it will very soon not be all
right. For the same reason, it seems like a bad design to set this up
so that the postmaster can't possibly use the mechanism safely. (Before
a couple of months ago, this wouldn't even have worked to replace the
existing use of SIGUSR1.) And in the third place, this doesn't work
unless one has one's hands on the target backend's PGPROC, and not
merely its PID. I object to the changes in sinvaladt.c altogether,
and note that this decision makes it impossible to fold SIGUSR2 handling
into the multiplex code, which is another simple proof that it fails to
qualify as a general-purpose multiplexer.
I think we need something closer to the postmaster signal multiplexing
mechanism, wherein there is a dedicated shared memory area of static
layout that holds the signaling flags. And it needs to be driven off
of knowing the target's PID, not anything else.
regards, tom lane