Re: [HACKERS] Terminating a backend

2008-03-10 Thread Bruce Momjian
Bruce Momjian wrote: I have an idea for this TODO item: * Allow administrators to safely terminate individual sessions either via an SQL function or SIGTERM Lock table corruption following SIGTERM of an individual backend has been reported in 8.0. A

Re: [HACKERS] Terminating a backend

2008-03-10 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: Bruce Momjian wrote: 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.

Re: [HACKERS] Terminating a backend

2008-03-10 Thread Alvaro Herrera
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Bruce Momjian wrote: 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

Re: [HACKERS] Terminating a backend

2008-03-10 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Bruce Momjian wrote: 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

Re: [HACKERS] Terminating a backend

2008-03-10 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: I am suggesting we add a new fuction pg_terminate_backend() that does everything just like cancel, but also sets a global variable that we check in the loop where we look for the next command and if it is set, we exit the backend. And if you never *get*

Re: [HACKERS] Terminating a backend

2008-03-10 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I am suggesting we add a new fuction pg_terminate_backend() that does everything just like cancel, but also sets a global variable that we check in the loop where we look for the next command and if it is set, we exit the backend.

Re: [HACKERS] Terminating a backend

2008-03-10 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: 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

Re: [HACKERS] Terminating a backend

2008-03-10 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: 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

[HACKERS] Terminating a backend

2008-03-06 Thread Bruce Momjian
I have an idea for this TODO item: * Allow administrators to safely terminate individual sessions either via an SQL function or SIGTERM Lock table corruption following SIGTERM of an individual backend has been reported in 8.0. A possible cause was

Re: [HACKERS] Terminating a backend

2008-03-06 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: I have an idea for this TODO item: ... 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

Re: [HACKERS] Terminating a backend

2008-03-06 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I have an idea for this TODO item: ... 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