Re: Backends stunk in wait event IPC/MessageQueueInternal

On Tue, May 17, 2022 at 3:31 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> On Mon, May 16, 2022 at 3:45 PM Japin Li <japinli(at)hotmail(dot)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