Re: Patch to allow users to kill their own queries

On 12/14/2011 05:24 AM, Magnus Hagander wrote:
> How about passing a parameter to pg_signal_backend? Making
> pg_signal_backend(int pid, int sig, bool allow_samerole)?
>    

That works, got rid of the parts I didn't like and allowed some useful 
minor restructuring.  I also made the HINT better and match style 
guidelines:

gsmith=> select pg_terminate_backend(21205);
ERROR:  must be superuser to terminate other server processes
HINT:  You can cancel your own processes with pg_cancel_backend().
gsmith=> select pg_cancel_backend(21205);
  pg_cancel_backend
-------------------
  t

New rev attached and pushed to 
https://github.com/greg2ndQuadrant/postgres/tree/cancel-backend (which 
is *not* the same branch as I used last time; don't ask why, long story)

I considered some additional ways to restructure the checks that could 
remove a further line or two from the logic here, but they all made the 
result seem less readable to me.  And this is not a high performance 
code path.  I may have gone a bit too far with the comment additions 
though, so feel free to trim that back.  It kept feeling weird to me 
that none of the individual signaling functions had their own intro 
comments.  I added all those.

I also wrote up a commentary on the PID wraparound race condition 
possibility Josh brought up.  Some research shows that pid assignment on 
some systems is made more secure by assigning new ones randomly.  That 
seems like it would make it possible to have a pid get reused much 
faster than on the usual sort of system that does sequential assignment 
and wraparound.  A reuse collision still seems extremely unlikely 
though.  With the new comments, at least a future someone who speculates 
on this will know how much thinking went into the current 
implementation:  enough to notice, not enough to see anything worth 
doing about it.  Maybe that's just wasted lines of text?

With so little grief on the last round, I'm going to guess this one will 
just get picked up by Magnus to commit next.  Marking accordingly and 
moved to the current CommitFest.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us