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
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!? |