I wrote: > All in all, this patch wasn't ready to apply without review. I'm > currently looking to see whether it's salvageable or not.
After further study, I've concluded that it is in fact not salvageable, and I respectfully request that it be reverted. I was able to get things to more or less work most of the time with three or four additional ugly hacks in postgres.c, but I still don't have any great confidence that there aren't windows where a terminate request wouldn't be ignored (even without considering the uncooperative- function scenario). Moreover it's entirely unclear that this approach actually dodges any of the hypothetical bugs in SIGTERM handling. Given the complexity that it adds, I think it's fair to say that this approach is probably buggier than the other way. I think if we want pg_terminate_backend, we have to do it the way that was originally discussed: have it issue SIGTERM and fix whatever needs to be fixed in the SIGTERM code path. As the TODO list used to say before it got editorialized upon, this is mostly a matter of testing (something that I can tell this patch was sadly lacking :-(). We do need also to go around and fix any places that think a PG_TRY block is a sufficient way to clean up state in shared memory --- cf this AFAIK-still-unfixed bug: http://archives.postgresql.org/pgsql-hackers/2007-04/msg00218.php regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
