Robert Haas <robertmh...@gmail.com> writes:
> Well, I'm not sure it would save anything meaningful to read the PID
> after releasing the lock even if it were safe, so I'd be inclined to
> keep things simple. But on further reflection I had us using the PID
> to find the target PGPROC in the first place, so we don't need to
> "remember" a value that we already know; that step is simply
> redundant.
I'm confused. If the premise is that PID is untrustworthy as a process
ID, how does searching PGPROC make it more trustworthy? The
hypothetical new owner of the PID could have gotten into PGPROC before
you begin to look.
What would make sense to me is to search PGPROC for some *other*
identifying property (and then set bit, remember PID, unlock, send
signal). But it seems like the key point here is what are we going
to use as an identifying property.
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
