Re: Multiplexing SUGUSR1

Tom Lane wrote:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
>> Thank you. Looks good to me, committed with minor changes.
>
> I don't think this patch is anywhere near ready to apply.

Ok, I'll revert it if you feel that strongly.

> 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.

Right, it does depend on that.

> 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'm surprised you feel that way. You suggested earlier
(http://archives.postgresql.org/message-id/28487.1221147665@sss.pgh.pa.us)
that a solution that only works for processes attached to shared memory
would probably suffice for now.

> 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.

That seems hard, considering that we also want it to work without
locking. Hmm, I presume we can use spinlocks in a signal handler?
Perhaps some sort of a hash table protected by a spinlock would work.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com