> 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 s
> 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 im
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
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 situat
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 inter