Re: [HACKERS] Questions regarding signal handler of postmaster
> But we keep signals blocked almost all the time in the postmaster, > so in reality no signal handler can interrupt anything except the > select() wait call. People complain about that coding technique > all the time, but no one has presented any reason to believe that > it's broken. Ok, there seems no better solution than always blocking signals. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp -- 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] Questions regarding signal handler of postmaster
> I encountered that problem with postmaster and fixed it in 9.4.0 (it's not > back-patched to earlier releases because it's relatively 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 not shut down promptly (MauMau, > Álvaro Herrera) > This reduces the likelihood of leaving orphaned child processes behind after > postmaster shutdown, as well as ensuring that crash recovery can proceed if > some child processes have become “stuck”. Looks wild to me:-) I hope there exists better way to solve the problem... Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp -- 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] Questions regarding signal handler of postmaster
From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@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's relatively 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 not shut down promptly (MauMau, Álvaro Herrera) This reduces the likelihood of leaving orphaned child processes behind after postmaster shutdown, as well as ensuring that crash recovery can proceed if some child processes have become “stuck”. Regards Takayuki Tsunakawa -- 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] Questions regarding signal handler of postmaster
Tatsuo Ishii writes: > 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(). But we keep signals blocked almost all the time in the postmaster, so in reality no signal handler can interrupt anything except the select() wait call. People complain about that coding technique all the time, but no one has presented any reason to believe that it's broken. 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
