Fujii Masao wrote:
Hi,
On Wed, Dec 10, 2008 at 1:43 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
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.
Thanks for the comment!
I updated the patch so. Is this patch ready to apply?
On closer look, I don't see anything setting ProcSignalData.pid field.
Which make me believe that the patch can't possibly 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
