Re: [HACKERS] Questions regarding signal handler of postmaster
От | Tsunakawa, Takayuki |
---|---|
Тема | Re: [HACKERS] Questions regarding signal handler of postmaster |
Дата | |
Msg-id | 0A3221C70F24FB45833433255569204D1F66CE61@G01JPEXMBYT05 обсуждение исходный текст |
Ответ на | [HACKERS] Questions regarding signal handler of postmaster (Tatsuo Ishii <ishii@sraoss.co.jp>) |
Ответы |
Re: [HACKERS] Questions regarding signal handler of postmaster
|
Список | pgsql-hackers |
From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Tatsuo Ishii > In postmaster.c signal handler pmdie() calls ereport() and > errmsg_internal(), which could call palloc() then malloc() if necessary. > Because it is possible that pmdie() gets called while > malloc() gets called in postmaster, I think it is possible that a deadlock > situation could occur through an internal locking inside malloc(). I have > not observed the exact case in PostgreSQL but I see a suspected case in > Pgpool-II. In the stack trace #14, malloc() is called by Pgpool-II. It is > interrupted by a signal in #11, and the signal handler calls malloc() again, > and it is stuck at #0. I encountered that problem with postmaster and fixed it in 9.4.0 (it's not back-patched to earlier releases because it'srelatively complex). https://www.postgresql.org/message-id/20DAEA8949EC4E2289C6E8E58560DEC0@maumau [Excerpt from 9.4 release note] During crash recovery or immediate shutdown, send uncatchable termination signals (SIGKILL) to child processes that do notshut down promptly (MauMau, Álvaro Herrera) This reduces the likelihood of leaving orphaned child processes behind after postmaster shutdown, as well as ensuring thatcrash recovery can proceed if some child processes have become “stuck”. Regards Takayuki Tsunakawa
В списке pgsql-hackers по дате отправления: