On 2017-04-20 00:50:13 -0400, Tom Lane wrote: > I wrote: > > Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > >> Tom Lane wrote: > >>> Hm. Do you have a more-portable alternative? > > >> I was thinking in a WaitEventSet from latch.c. > > My first reaction was that that sounded like a lot more work than removing > two lines from maybe_start_bgworker and adjusting some comments. But on > closer inspection, the slow-bgworker-start issue isn't the only problem > here. On a machine that restarts select()'s timeout after an interrupt, > as (at least) HPUX does, the postmaster will actually never iterate > ServerLoop's loop except immediately after receiving a new connection > request. The stream of interrupts from the autovac launcher is alone > sufficient to prevent the initial 60-second timeout from ever elapsing. > So if there are no new connection requests for awhile, none of the > housekeeping actions in ServerLoop get done.
FWIW, I vaguely remember somewhat related issues on x86/linux too. On busy machines in autovacuum_freeze_max_age territory (pretty frequent thing these days), the signalling frequency caused problems in postmaster, but I unfortunately don't remember the symptoms very well. > So it's looking to me like we do need to do something about this, and > ideally back-patch it all the way. But WaitEventSet doesn't exist > before 9.6. Do we have the stomach for back-patching that into > stable branches? Hm, that's not exactly no code - on the other hand it's (excepting the select(2) path) reasonably well exercised. What we could do is to convert master, see how the beta process likes it, and then backpatch? These don't like super pressing issues. - Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
