On Tue, Mar 20, 2012 at 12:48 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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.
Hmm, I guess that's true. > 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. Well, Dan's idea of an ascending 64-bit sequence number would work, but then we'd have to whack around the API to pg_cancel_backend and pg_terminate_backend to accept that identifier in lieu of a PID, or have alternate versions defined that way, and we'd have to export the identifiers through pg_stat_activity as well. Maybe we should just not worry about this. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers