Re: PostmasterContext survives into parallel workers!?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PostmasterContext survives into parallel workers!?
Date: 2016-08-01 23:42:28
Message-ID: 22056.1470094948@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Karan Sikka 2016-08-01 23:47:49 Re: TODO item: Implement Boyer-Moore searching in LIKE queries
Previous Message Andres Freund 2016-08-01 23:36:52 Re: PostmasterContext survives into parallel workers!?