Re: [HACKERS] Unportable implementation of background worker start

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: [HACKERS] Unportable implementation of background worker start
Дата
Msg-id 20170421030031.a4wj7xjwt2zn6lm6@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: [HACKERS] Unportable implementation of background worker start  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 2017-04-20 20:10:41 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] DROP SUBSCRIPTION, query cancellations and slot handling
Следующее
От: Noah Misch
Дата:
Сообщение: Re: [HACKERS] Quorum commit for multiple synchronous replication.