Re: [HACKERS] Terminating a backend
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] Terminating a backend |
Дата | |
Msg-id | 200804121532.m3CFW0Y23826@momjian.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Terminating a backend (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: [HACKERS] Terminating a backend
|
Список | pgsql-patches |
Bruce Momjian wrote: > 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. > > I have implemented this idea with the attached patch. One problem I have with my patch is that SIGTERM is currently used by the postmaster to shut down backends. Now because the postmaster knows that all backend are terminating, it can accept a dirtier shutdown than one where we are terminating just one backend and the rest are going to keep running. The new SIGTERM coding is going to exit a backend only in a place where cancel is checked. I need some thoughts in this area. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-patches по дате отправления: