Re: Optimize LISTEN/NOTIFY - Mailing list pgsql-hackers

From Joel Jacobson
Subject Re: Optimize LISTEN/NOTIFY
Date
Msg-id 294e1641-d658-4d43-8671-60e8ff860532@app.fastmail.com
Whole thread Raw
In response to Re: Optimize LISTEN/NOTIFY  ("Joel Jacobson" <joel@compiler.org>)
Responses Re: Optimize LISTEN/NOTIFY
List pgsql-hackers
On Fri, Nov 7, 2025, at 19:59, Joel Jacobson wrote:
> * The logic in SignalBackends has been reworked and simplified,
>   thanks to the new isAdvancing and advancingPos fields.
>   I now think it's finally easy to reason about why each branch
>   in SignalBackends must be correct.

I was wrong. I wrongly assumed asyncQueueReadAllNotifications would read
up until head, which it might not actually do:

    * Process messages up to the stop position, end of page, or an
    * uncommitted message.

This in turn could cause a listening backend to remain behind, if there
would be no more notifies, so it unfortunately seems like we will always
need to signal when a backend isAdvancing, and therefore have no use of
the advancingPos field.

I will do more correctness and benchmark testing before posting a new
version. Just wanted to give you a heads up on the bug, so you don't
waste time reviewing.

/Joel



pgsql-hackers by date:

Previous
From: Antonin Houska
Date:
Subject: Re: Use bsearch() instead of a manual binary search in syscache.c
Next
From: Thomas Munro
Date:
Subject: Re: Use bsearch() instead of a manual binary search in syscache.c