On Tue, Mar 20, 2012 at 12:48 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@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
