| 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-11 16:34:39 |
| Message-ID: | 7456ec96-7a9c-45a0-988e-ba1c7f9ec937@app.fastmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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 | Content-Type | Size |
|---|---|---|
| 0001-optimize_listen_notify-v26.patch | application/octet-stream | 9.3 KB |
| 0002-optimize_listen_notify-v26.patch | application/octet-stream | 43.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2025-11-11 16:36:32 | Re: another autovacuum scheduling thread |
| Previous Message | Daniel Gustafsson | 2025-11-11 16:23:16 | Re: pg_getaddrinfo_all() with hintp=NULL |