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

From: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
To: Thomas Munro <thomas(dot)munro(at)gmail(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 16:13:32
Message-ID: CAOYmi+n1xRNCDnwZzigXVk8V=+sr7ZzuGpJ0tAyozX-zQT19Gg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Aug 6, 2025 at 8:04 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> * 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.

I think the weaker guarantee might be sufficient. I was trying to get
a stronger primitive in place so that we wouldn't have to worry about
it down the line, but it is a lot of code to pay...

One sharp edge of that strategy is caught by the new tests, which is
that if you call drain_socket_events() and then unset the timer, your
multiplexer is still readable until you call drain_socket_events() yet
again. At the moment, our code only ever calls those two in the
opposite order (due to the race condition pointed out in 0002); we'd
just have to keep that in mind. Maybe "drain" would no longer be the
verb to use there.

--Jacob

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Jones 2025-08-06 16:13:45 Re: [PATCH] Add CANONICAL option to xmlserialize
Previous Message Ashutosh Bapat 2025-08-06 15:10:00 Re: Test to dump and restore objects left behind by regression