From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Daniel Farina <daniel(at)heroku(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Cross-backend signals and administration (Was: Re: pg_terminate_backend for same-role) |
Date: | 2012-03-20 17:07:50 |
Message-ID: | CA+TgmobT=kHhJcRTR+rJ1h5ef9XmKX2xMV9Riy3R-yufFeUnQw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-03-20 17:13:01 | Re: Cross-backend signals and administration (Was: Re: pg_terminate_backend for same-role) |
Previous Message | Robert Haas | 2012-03-20 17:04:29 | Re: Memory usage during sorting |