On Mon, Mar 19, 2012 at 9:08 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> 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.
I chose the SessionId mostly because I didn't have a great sense
around how hot the ProcArrayLock is, and it was easy to add a
fine-grained spinlock to just get the flavor of the idea.
To attempt to simplify your protocol more: is it necessary or sound to
remember the PID at all if one takes a lock on the entire PGPROC
array? At that point backend birth and death contends against that
lock, so the postmaster just has to initialize PGPROC the usual way
(writing over the administrative action words) and then...I don't see
a problem, on first blush. But I'll see your midnight and raise you a
1:35 AM.
I do think a session identifier will be useful someday in Postgres's
future, but it only really is worth it if it is non-guessable, to
which my implementation need not apply.
Also, I had a use case that would be roughly right for "cross-backend
administration" I want to temporarily suppress autovacuum/autoanalyze
without having to muck with thrashing configuration files, if
possible.
--
fdr
