Re: Optimize LISTEN/NOTIFY

From: "Joel Jacobson" <joel(at)compiler(dot)org>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Optimize LISTEN/NOTIFY
Date: 2025-11-08 12:59:21
Message-ID: 294e1641-d658-4d43-8671-60e8ff860532@app.fastmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2025-11-08 13:24:34 Re: Use bsearch() instead of a manual binary search in syscache.c
Previous Message Antonin Houska 2025-11-08 12:12:31 Re: Use bsearch() instead of a manual binary search in syscache.c