Horton

Re: Optimize LISTEN/NOTIFY

Joel Jacobson <joel@compiler.org>

View thread
From: "Joel Jacobson" <joel@compiler.org>
To: "Chao Li" <li.evan.chao@gmail.com>
Cc: "Tom Lane" <tgl@sss.pgh.pa.us>, "Thomas Munro" <thomas.munro@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, "Heikki Linnakangas" <hlinnaka@iki.fi>, "Rishu Bagga" <rishu.postgres@gmail.com>
Date: 2025-09-26T09:32:29Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Optimize LISTEN/NOTIFY via shared channel map and direct advancement.

  2. Fix incorrect logic for caching ResultRelInfos for triggers

On Fri, Sep 26, 2025, at 04:26, Chao Li wrote:

> I think what you explained is partially correct.
>
> Based on my understanding, any backend process may call 
> SignalBackends(), which means that it’s possible that multiple backend 
> processes may call SignalBackends() concurrently.
>
> Looking at your code, between checking 
> QUEUE_BACKEND_WAKEUP_PENDING_FLAG(i) and set the flag to true, there is 
> a block of code (the “if-else”) to run, so that it’s possible that 
> multiple backend processes have passed the 
> QUEUE_BACKEND_WAKEUP_PENDING_FLAG(i) check, then multiple signals will 
> be sent to a process, which will lead to duplicate timeout enabled in 
> the receiver process.

I don't see how that can happen; we're checking wakeup_pending_flag
while holding an exclusive lock, so I don't see how multiple backend
processes could be within the region where we check/set
wakeup_pending_flag, at the same time?

/Joel