Re: [HACKERS] Function to kill backend
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Function to kill backend |
Дата | |
Msg-id | 7254.1090701355@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Function to kill backend (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] Function to kill backend
|
Список | pgsql-patches |
Bruce Momjian <pgman@candle.pha.pa.us> writes: > I have applied the attached patch: > Exit backend from SIGTERM or FATAL by simulating client EOF, rather than > calling proc_exit() directly. This should make SIGTERM more reliable. After further consideration I have concluded that this was a spectacularly bad idea and we should revert that patch. There is a very large amount of processing that this patch will cause to happen after a FATAL error has been declared, and I doubt that any of it is a good idea. Some examples: * AbortCurrentTransaction() --- not too cool if the FATAL error was one of the ones in xact.c that are complaining of fatally bollixed transaction state. * pgstat reporting --- aside from the chance of an outright crash, we might be transmitting bogus statistics to the collector. * sending a ReadyForQuery (Z) message --- one thing we quite certainly ain't is ReadyForQuery. * EnableNotifyInterrupt --- this may result in actually trying to run a transaction to look through pg_listener :-( * ProcessConfigFile, if we had a pending SIGHUP --- also not too cool, if the FATAL was from guc.c. I am still dubious that zapping random backends with SIGTERM is a sane or supportable idea. But this patch does not make things better, it simply greatly increases the chance of a FATAL exit turning into a backend crash or PANIC. regards, tom lane
В списке pgsql-patches по дате отправления: