| 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
| 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 |