Re: [HACKERS] PATCH: Keep one postmaster monitoring pipe per process

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: [HACKERS] PATCH: Keep one postmaster monitoring pipe per process
Дата
Msg-id CAEepm=03xOCRVht677g_ARt9jRQ+vu6AunfnNBUdK3+x-E7Wyg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] PATCH: Keep one postmaster monitoring pipe per process  (Andres Freund <andres@anarazel.de>)
Ответы Re: [HACKERS] PATCH: Keep one postmaster monitoring pipe per process  (Thomas Munro <thomas.munro@enterprisedb.com>)
Список pgsql-hackers
On Wed, Apr 11, 2018 at 12:26 PM, Andres Freund <andres@anarazel.de> wrote:
> On 2018-04-11 12:17:14 +1200, Thomas Munro wrote:
>> I arrived at this idea via the realisation that the closest thing to
>> prctl(PR_SET_PDEATHSIG) on BSD-family systems today is
>> please-tell-my-kqueue-if-this-process-dies.  It so happens that my
>> kqueue patch already uses that instead of the pipe to detect
>> postmaster death.  The only problem is that you have to ask it, by
>> calling it kevent().  In a busy loop like those two, where there is no
>> other kind of waiting going on, you could do that by calling kevent()
>> with timeout = 0 to check the queue.
>
> Which is not cheap.

Certainly, but I am reacting to reports via you of performance
problems coming from read(heavily_contended_fd) by saying: although we
can't avoid a syscall like Linux can in this case, we *can* avoid the
reportedly contended pipe mutex completely by reading only our own
process's kqueue.  Combined with Heikki's proposal not to check every
single time through busy loops to reduce the syscall frequency, that
might be the optimal solution until some hypothetical
prctl(PR_SET_PDEATHSIG)-feature-match patch arrives.  Just a thought.

-- 
Thomas Munro
http://www.enterprisedb.com


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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: WIP: Covering + unique indexes.
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Gotchas about pg_verify_checksums