Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> 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.
Well, I wasn't complaining about the dependence on being attached to
shared memory. What I'm complaining about is the dependence on the
rather complex PGPROC data structure.
> 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.
No, locks are right out if the postmaster is supposed to be able to use
it. What I was thinking of is a simple linear array of PIDs and
sig_atomic_t flags. The slots could be assigned on the basis of
backendid, but callers trying to send a signal would have to scan the
array looking for the matching PID. (This doesn't seem outlandishly
expensive considering that one is about to do a kernel call anyway.
You might be able to save a few cycles by having the PID array separate
from the flag array, which should improve the cache friendliness of the
scan.) Also, for those callers who do have access to a PGPROC, there
could be a separate entry point that passes backendid instead of PID to
eliminate the search.
regards, tom lane
