Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> 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/[EMAIL PROTECTED])
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
