On Mon, Aug 1, 2016 at 7:42 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Thomas Munro <thomas.mu...@enterprisedb.com> writes: >> I found this apparently unresolved bug report about glibc fork() >> inside a signal handler deadlocking: >> https://sourceware.org/bugzilla/show_bug.cgi?id=4737 > >> I wonder if that could bite postmaster. > > I seriously doubt it. The key thing about the postmaster is that > it runs with signals blocked practically everywhere. So we're not > taking risks of a signal handler interrupting, say, malloc() > (which seemed to be the core of at least the first example given > in that report). This is what makes me dubious that getting rid > of doing work in the postmaster's signal handlers is really going > to add any noticeable increment of safety. It might make the > code look cleaner, but I'm afraid it's going to be a lot of churn > for not much gain.
It's not just a cosmetic issue. See https://www.postgresql.org/message-id/CA+Tgmobr+Q2WgWeasdbDNefVwJkAGALxA=-vtegntqgl1v2...@mail.gmail.com and d0410d66037c2f3f9bee45e0a2db9e47eeba2bb4. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
