Re: Cross-backend signals and administration (Was: Re: pg_terminate_backend for same-role)

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