Re: [HACKERS] Terminating a backend
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 possible cause was fixed in 8.1, but it is unknown whether other problems exist. This item mostly requires additional testing rather than of writing any new code. http://archives.postgresql.org/pgsql-hackers/2006-08/msg00174.php 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. Should I add this as a TODO? Seems so. Tom commented in the patches queue that it will not work but I don't understand why. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Terminating a backend
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. Should I add this as a TODO? Seems so. Tom commented in the patches queue that it will not work but I don't understand why. The problem with treating it like elog(ERROR) is that you're at the mercy of user-defined code as to whether you'll actually exit or not. UDFs can trap elog(ERROR). 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
Re: [HACKERS] Terminating a backend
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 can exit cleanly. Should I add this as a TODO? Seems so. Tom commented in the patches queue that it will not work but I don't understand why. The problem with treating it like elog(ERROR) is that you're at the mercy of user-defined code as to whether you'll actually exit or not. UDFs can trap elog(ERROR). Well, we can punt and blame the writer of the UDF if the signal is not timely honored. Having something that works for 98% of the cases, can be fixed for 1% of the remainder, and only fails in 1% (proprietary code that cannot be fixed) is better than having nothing at all. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Terminating a backend
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 can exit cleanly. Should I add this as a TODO? Seems so. Tom commented in the patches queue that it will not work but I don't understand why. The problem with treating it like elog(ERROR) is that you're at the mercy of user-defined code as to whether you'll actually exit or not. UDFs can trap elog(ERROR). I don't understand. I was never considering elog(ERROR). Right now for cancel we have: pqsignal(SIGINT, StatementCancelHandler); 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. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Terminating a backend
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* to that loop, what have you accomplished? 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. 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
Re: [HACKERS] Terminating a backend
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. And if you never *get* to that loop, what have you accomplished? 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. What I hear people ask is that they don't want the backend to read the next command but to exit. That seems like a reasonable request. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Terminating a backend
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 don't think it's a step forward. What I hear people ask is that they don't want the backend to read the next command but to exit. That seems like a reasonable request. [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. 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
Re: [HACKERS] Terminating a backend
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 get them out of, I don't think it's a step forward. What I hear people ask is that they don't want the backend to read the next command but to exit. That seems like a reasonable request. [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 am kind of confused by your reaction to my idea. I thought we agreed that there was going to be no way to cleanly terminate a backend at an arbitrary time, and I thought we were getting better at having query cancel work in most cases, so it seems combining these two ideas that query cancel with an immediate exit from the query loop was a perfect solution to a feature request we get regularly. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Terminating a backend
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 exit cleanly. How does that differ from what happens now? 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
Re: [HACKERS] Terminating a backend
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 released all locks and can exit cleanly. How does that differ from what happens now? We would _terminate_/exit, not just cancel the query. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
