On Tue, 2012-03-20 at 01:38 -0700, Daniel Farina wrote: > On Thu, Mar 15, 2012 at 9:39 PM, Fujii Masao <masao.fu...@gmail.com> wrote: > > On Fri, Mar 16, 2012 at 8:14 AM, Daniel Farina <dan...@heroku.com> 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 > > Here's a patch implementing the simple version, with no more guards > against signal racing than have been seen previously. The more > elaborate variants to close those races is being discussed in a > parallel thread, but I thought I'd get this simple version out there.
Review: After reading through the threads, it looks like there was no real objection to this approach -- pid recycling is not something we're concerned about. I think you're missing a doc update though, in func.sgml: "For the less restrictive <function>pg_cancel_backend</>, the role of an active backend can be found from the <structfield>usename</structfield> column of the <structname>pg_stat_activity</structname> view." Also, high-availability.sgml makes reference to pg_cancel_backend(), and it might be worthwhile to add an "...and pg_terminate_backend()" there. Other than that, it looks good to me. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers