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

From Joel Jacobson
Subject Re: Optimize LISTEN/NOTIFY
Date
Msg-id 7456ec96-7a9c-45a0-988e-ba1c7f9ec937@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 Sat, Nov 8, 2025, at 16:04, Joel Jacobson wrote:
> On Sat, Nov 8, 2025, at 13:59, Joel Jacobson wrote:
>> On Fri, Nov 7, 2025, at 19:59, Joel Jacobson wrote:
>> 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.

Having thought about this, I don't think this is actually a problem,
since this isn't any worse than what we currently have in master.
Listening backends can currently end up stationary behind QUEUE_HEAD, in
exactly this situation, when they don't read up until QUEUE_HEAD in
asyncQueueReadAllNotifications. In this case, we currently rely on
another NOTIFY to wake them up, so v24 wouldn't be any worse.

My apologies for again making the mistake of mixing in robustness
improvements into this patch. I must keep in mind this is solely an
optimization patch.

I'm therefore attaching v24 again, but renamed to v26.

/Joel
Attachment

pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: pg_getaddrinfo_all() with hintp=NULL
Next
From: Nathan Bossart
Date:
Subject: Re: another autovacuum scheduling thread