Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> When we get the termination signal, why can't we just set a global
> >> boolean, do a query cancel, and in the setjmp() code block check the
> >> global and exit --- at that stage we know we have released all locks and
> >> can exit cleanly.
>
> > I have implemented this idea with the attached patch.
>
> It was already explained to you why this is a bad idea.
Yes, I remember your comments:
http://archives.postgresql.org/pgsql-hackers/2008-03/msg00145.php
Keep in mind that 99% of the excuse for people to want to use SIGTERM is
that the backend isn't responding to SIGINT. If you've fixed things so
that SIGTERM cannot get them out of any situation that SIGINT doesn't
get them out of, I don't think it's a step forward.
...
[shrug...] They can do that now, most of the time. What this is about
is dealing with corner cases, and in that respect what your proposal
will do is replace soluble problems with insoluble ones. But I suppose
I can't stop you if you're insistent.
I need more than one person to tell me it is a bad idea because I think
it is a good idea.
If we tell people SIGTERM is not safe to use then why is making it safe
worse. And if it is safe, we can just add a function to enable SIGTERM
to the backend without doing the query cancel longjump().
--
Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
