Skip site navigation (1) Skip section navigation (2)

Re: Unportable implementation of background worker start

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Unportable implementation of background worker start
Date: 2017-04-22 05:54:44
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 2017-04-21 23:50:41 -0400, Tom Lane wrote:
> Attached are a couple of patches that represent a plausible Plan B.
> The first one changes the postmaster to run its signal handlers without
> specifying SA_RESTART.  I've confirmed that that seems to fix the
> select_parallel-test-takes-a-long-time problem on gaur/pademelon.

> The second one uses pselect, if available, to replace the unblock-signals/
> select()/block-signals dance in ServerLoop.  On platforms where pselect
> exists and works properly, that should fix the race condition I described
> previously.  On platforms where it doesn't, we're no worse off than
> before.

We probably should note somewhere prominently that pselect isn't
actually race-free on a number of platforms.

> I think that these patches represent something we could back-patch
> without a lot of trepidation, unlike the WaitEventSet-based approach.
> Therefore, my proposal is to apply and backpatch these changes, and
> call it good for v10.  For v11, we could work on changing the postmaster
> to not do work in signal handlers, as discussed upthread.  That would
> supersede these two patches completely, though I'd still advocate for
> keeping the change in maybe_start_bgworker.

Not yet having looked at your patches, that sounds like a reasonable
plan.  I'd still like to get something like your CLOEXEC patch applied
independently however.

< patches >

Looks reasonable on a quick skim.


Andres Freund

In response to


pgsql-hackers by date

Next:From: Dean RasheedDate: 2017-04-22 08:08:56
Subject: Re: WITH clause in CREATE STATISTICS
Previous:From: Thomas MunroDate: 2017-04-22 05:45:15
Subject: Re: [COMMITTERS] pgsql: Replication lag tracking for walsenders

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group