Tom Lane wrote:
> 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.
OK, 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.
I don't understand. If we call proc_exit(0) instead, it is the same as
someone exiting the backend via PQfinish().
> 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
Well, with no movement on this TODO item since it was removed in 8.0, I
am willing to give users something that works most of the time. As you
said already, cancel isn't going to be 100% reliable anyway because of
places we can't check for cancel.
I will work on a new version of the patch that people can see.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
