Re: [PATCH] OAuth: fix performance bug with stuck multiplexer events

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Peter Eisentraut <peter(at)eisentraut(dot)org>
Subject: Re: [PATCH] OAuth: fix performance bug with stuck multiplexer events
Date: 2025-08-06 15:03:57
Message-ID: CA+hUKG+H1gwDh96jn5jB6Q3HyXrSC9x2y=uQJAthT8NLs6GN_Q@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 5, 2025 at 3:24 AM Jacob Champion
<jacob(dot)champion(at)enterprisedb(dot)com> wrote:
> On Mon, Aug 4, 2025 at 7:53 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> > [FYI, I'm looking into this and planning to post a review in 1-2 days...]

0001:

So, the problem is that poll(kqueue_fd) reports POLLIN if any events
are queued, but level-triggered events are only rechecked and possibly
cancelled if you actually call kevent(). Hmm, what if you just called
kevent() with an output array of size one?

* If it returns 0, that means it has rechecked all queued
level-triggered events and booted them all out because they are no
longer true. poll(fd) won't report POLLIN until one of them is queued
again.

* If it returns 1, then it stopped on the first level-triggered event
that it rechecked and found to be still true. Who cares if there are
more that didn't get rechecked? poll(fd) will report POLLIN either
way, and that's what you want.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2025-08-06 15:10:00 Re: Test to dump and restore objects left behind by regression
Previous Message Andrey Borodin 2025-08-06 14:59:58 VM corruption on standby