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