Horton

Re: [HACKERS] Unportable implementation of background worker start

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Rémi Zara <remi_zara@mac.com>, cm@enterprisedb.com, Alvaro Herrera <alvherre@2ndquadrant.com>, pgsql-hackers@postgresql.org
Date: 2019-02-11T11:07:03Z
Lists: pgsql-hackers 
Hi,

On 2017-04-26 11:42:38 -0400, Tom Lane wrote:
> 3. Go ahead with converting the postmaster to use WaitEventSet, a la
> the draft patch I posted earlier.  I'd be happy to do this if we were
> at the start of a devel cycle, but right now seems a bit late --- not
> to mention that we really need to fix 9.6 as well.

Btw, recent-ish versions of
http://man7.org/linux/man-pages/man7/signal-safety.7.html
have
       *  POSIX.1-2003 clarified that if an application calls fork(2) from a
          signal handler and any of the fork handlers registered by
          pthread_atfork(3) calls a function that is not async-signal-safe,
          the behavior is undefined.  A future revision of the standard is
          likely to remove fork(2) from the list of async-signal-safe
          functions.

Greetings,

Andres Freund

Commits

  1. Cope with glibc too old to have epoll_create1().

  2. Make latch.c more paranoid about child-process cases.

  3. Allow multiple bgworkers to be launched per postmaster iteration.

  4. Revert "Use pselect(2) not select(2), if available, to wait in postmaster's loop."

  5. Use pselect(2) not select(2), if available, to wait in postmaster's loop.

  6. Run the postmaster's signal handlers without SA_RESTART.

  7. Fix postmaster's handling of fork failure for a bgworker process.

  8. Partially revert commit 536d47bd9d5fce8d91929bee3128fa1d08dbcc57.

  9. Avoid depending on non-POSIX behavior of fcntl(2).

  10. Remove long-obsolete catering for platforms without F_SETFD/FD_CLOEXEC.