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. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers