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-21 03:00:31 |
Message-ID: | 20170421030031.a4wj7xjwt2zn6lm6@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2017-04-20 20:10:41 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2017-04-20 20:05:02 -0400, Tom Lane wrote:
> >> Also, if it's not there we'd fall back to using plain poll(), which is
> >> not so awful that we need to work hard to avoid it. I'd just as soon
> >> keep the number of combinations down.
>
> > Just using fcntl(SET, CLOEXEC) wound't increase the number of
> > combinations?
>
> True, if you just did it that way unconditionally. But doesn't that
> require an extra kernel call per CreateWaitEventSet()?
It does - the question is whether that matters much. FE/BE uses a
persistent wait set, but unfortunately much of other latch users
don't. And some of them can be somewhat frequent - so I guess that'd
possibly be measurable. Ok, so I'm on board with epoll1.
If somebody were to change more frequent latch users to use persistent
wait sets, that'd be good too.
- Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2017-04-21 03:02:40 | Re: Quorum commit for multiple synchronous replication. |
Previous Message | Michael Paquier | 2017-04-21 02:57:13 | Re: DROP SUBSCRIPTION, query cancellations and slot handling |