On Fri, Mar 16, 2012 at 3:42 PM, Noah Misch <n...@leadboat.com> wrote: > On Thu, Mar 15, 2012 at 04:14:03PM -0700, Daniel Farina wrote: >> Parallel to pg_cancel_backend, it'd be nice to allow the user to just >> outright kill a backend that they own (politely, with a SIGTERM), >> aborting any transactions in progress, including the idle transaction, >> and closing the socket. > > +1 > >> I imagine the problem is a race condition whereby a pid might be >> reused by another process owned by another user (doesn't that also >> affect pg_cancel_backend?). Shall we just do everything using the >> MyCancelKey (which I think could just be called "SessionKey", >> "SessionSecret", or even just "Session") as to ensure we have no case >> of mistaken identity? Or does that end up being problematic? > > No, I think the hazard you identify here is orthogonal to the question of when > to authorize pg_terminate_backend(). As you note downthread, protocol-level > cancellations available in released versions already exhibit this hazard. I > wouldn't mind a clean fix for this, but it's an independent subject.
Hmm. Well, here's a patch that implements exactly that, I think, similar to the one posted to this thread, but not using BackendIds, but rather the newly-introduced "SessionId". Would appreciate comments. Because an out-of-band signaling method has been integrated more complex behaviors -- such as closing the TERM-against-SECURITY-DEFINER-FUNCTION hazard -- can be addressed. For now I've only attempted to solve the problem of backend ambiguity, which basically necessitated out-of-line information transfer as per the usual means. > Here I discussed a hazard specific to allowing pg_terminate_backend(): > http://archives.postgresql.org/message-id/20110602045955.gc8...@tornado.gateway.2wire.net > > To summarize, user code can trap SIGINT cancellations, but it cannot trap > SIGTERM terminations. If a backend is executing a SECURITY DEFINER function > when another backend of the same role calls pg_terminate_backend() thereon, > the pg_terminate_backend() caller could achieve something he cannot achieve in > PostgreSQL 9.1. I vote that this is an acceptable loss. I'll throw out a patch that just lets this hazard exist and see what happens, although it is obsoleted/incompatible with the one already attached. -- fdr
Implement-race-free-sql-originated-backend-cancellation-v2.patch.gz
Description: GNU Zip compressed data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
