From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Daniel Farina <daniel(at)heroku(dot)com> |
Cc: | 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 04:08:22 |
Message-ID: | CA+TgmoaasuaRq4NZb8Gxqh+4yoC9ArSkC5cBpbrUDP=s0V87Mw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Mar 17, 2012 at 8:28 PM, Daniel Farina <daniel(at)heroku(dot)com> wrote:
> This thread evolved out of an attempt to implement
> pg_terminate_backend for non-superusers. I thought -- probably
> erroneously -- that the major objection to that was the known
> possibility of a PID-cycling race condition, whereby a signal could be
> misdirected, in the case of terminate_backend, SIGTERM. So now this
> fork of the thread is about fixing these unlikely races, and then
> passing administration requests (such as "query cancel" or "die" ) as
> out-of-band information via SIGUSR1, just like how LISTEN/NOTIFY and
> conflict signals are passed.
>
> To prevent ambiguity, I am using a new special number -- a 'SessionId'
> -- that is guaranteed unique to all backends ever created during the
> uptime of a database. This number is currently implemented in a way
> that is guessable (so it cannot be accepted from external sources),
> but I actually think it may be even more useful for a number of other
> uses if given a non-guessable form (like cancellation keys). In this
> respect it would fulfill pretty much the same purposes as the notion
> of a "session" seen on the web.
It's after midnight here so maybe I'm being slow, but I don't
understand what problem the SessionId solves. ISTM that you could
solve the problem like this:
1. Acquire ProcArrayLock in exclusive mode, to keep the set of PGPROCs
from changing.
2. Search for the target PGPROC by PID; when you find it, set a bit in
the PGPROC indicating that you want it to cancel/die/whatever.
3. Remember the PID.
4. Release ProcArrayLock.
5. Send SIGUSR1.
If the PGPROC gets recycled between 4 and 5, the target backend will
find the relevant bits no longer set, and will do nothing.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Erik Rijkers | 2012-03-20 04:13:07 | Re: patch for parallel pg_dump |
Previous Message | Erik Rijkers | 2012-03-20 04:03:06 | Re: patch for parallel pg_dump |