Re: Backends stunk in wait event IPC/MessageQueueInternal

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: Backends stunk in wait event IPC/MessageQueueInternal
Дата
Msg-id CA+hUKGKPUGVdX+JV0GxHywaER4=BAVsaDGeDBef5=rkvQazsCw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Backends stunk in wait event IPC/MessageQueueInternal  (Thomas Munro <thomas.munro@gmail.com>)
Ответы Re: Backends stunk in wait event IPC/MessageQueueInternal  (Thomas Munro <thomas.munro@gmail.com>)
Список pgsql-hackers
On Tue, May 17, 2022 at 3:31 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> On Mon, May 16, 2022 at 3:45 PM Japin Li <japinli@hotmail.com> wrote:
> > Maybe use the __illumos__ macro more accurity.
> >
> > +#elif defined(WAIT_USE_EPOLL) && defined(HAVE_SYS_SIGNALFD_H) && \
> > +       !defined(__sun__)
>
> Thanks, updated, and with a new commit message.

Pushed to master and REL_14_STABLE.

I'll email the illumos build farm animal owners to say that they
should be able to remove -DWAIT_USE_POLL.

Theoretically, it might be useful that we've separated the
WAIT_USE_SELF_PIPE code from WAIT_USE_POLL if someone eventually wants
to complete the set of possible WaitEventSet implementations by adding
/dev/poll (Solaris, HPUX) and pollset (AIX) support.  I don't think
those have a nicer way to receive race-free signal wakeups.
Realistically no one's likely to show up with a patch for those old
proprietary Unixen at this point on the timeline, I just think it's
interesting that every OS had something better than poll(), we just
need that fallback for lack of patches, not lack of kernel features.
Ironically the typical monster AIX systems I've run into in the wild
are probably much more capable of suffering from poll() contention
than all these puny x86 systems, with oodles of CPUs and NUMA nodes.
If someone *is* still interested in scalability on AIX, I'd recommend
looking at pollset for latch.c, and also the stalled huge pages
thing[1].

[1] https://www.postgresql.org/message-id/CA%2BhUKGJE4dq%2BNZHrm%3DpNSNCYwDCH%2BT6HtaWm5Lm8vZzygknPpA%40mail.gmail.com



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

Предыдущее
От: Hannu Krosing
Дата:
Сообщение: Re: Hardening PostgreSQL via (optional) ban on local file system access
Следующее
От: Julien Rouhaud
Дата:
Сообщение: Re: NAMEDATALEN increase because of non-latin languages