Re: PostmasterContext survives into parallel workers!?
От | Robert Haas |
---|---|
Тема | Re: PostmasterContext survives into parallel workers!? |
Дата | |
Msg-id | CA+TgmoY1zUBri87PXsJdOFiGW0prHeM4o1Q=p=dd-c+7G8-SHg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PostmasterContext survives into parallel workers!? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: PostmasterContext survives into parallel workers!?
|
Список | pgsql-hackers |
On Mon, Aug 1, 2016 at 7:42 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Thomas Munro <thomas.munro@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=-VtEGNtQgL1V2Ryw@mail.gmail.com and d0410d66037c2f3f9bee45e0a2db9e47eeba2bb4. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: