Re: pg_terminate_backend for same-role

On Thu, Mar 15, 2012 at 11:01 PM, Daniel Farina <daniel@heroku.com> wrote:
> Okay, well, I believe there is a race in handling common
> administrative signals that *might* possibly matter.  In the past,
> pg_cancel_backend was superuser only, which is a lot like saying "only
> available to people who can be the postgres user and run kill."  The
> cancellation packet is handled via first checking the other backend's
> BackendKey and then SIGINTing it, leaving only the most narrow
> possibility for a misdirected SIGINT.

Attached is a patch that sketches a removal of the caveat by relying
on the BackendId in PGPROC instead of the pid.  Basically, the idea is
to make it work more like how cancellation keys work, except for
internal SQL functions.  I think the unsatisfying crux here is the
uniqueness of BackendId over the life of one *postmaster* invocation:

sinvaladt.c

    MyBackendId = (stateP - &segP->procState[0]) + 1;
    /* Advertise assigned backend ID in MyProc */
    MyProc->backendId = MyBackendId;

I'm not sure precisely what to think about how this numbering winds up
working on quick inspection.  Clearly, if BackendIds can be reused
quickly then the pid-race problem comes back in spirit right away.

But given the contract of MyBackendId as I understand it (it just has
to be unique among all backends at any given time), it could be
changed.  I don't *think* it's used for its arithmetic relationship to
its underlying components anywhere.

Another similar solution (not attached) would be to send information
about the originating backend through PGPROC and having the check be
against those rather than merely a correct and unambiguous
MyBackendId.

I also see now that cancellation packets does not have this caveat
because the postmaster is control of all forking and joining in a
serially executed path, so it need not worry about pid racing.

Another nice use for this might be to, say, deliver the memory or
performance stats of another process while-in-execution, without
having to be superuser or and/or gdbing in back to the calling backend.

--
fdr