Re: Terminating a backend
От | Bruce Momjian |
---|---|
Тема | Re: Terminating a backend |
Дата | |
Msg-id | 200803101822.m2AIMKv12176@momjian.us обсуждение исходный текст |
Ответ на | Re: Terminating a backend (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Terminating a backend
|
Список | pgsql-hackers |
Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> 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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-hackers по дате отправления: