Horton

Re: Optimize LISTEN/NOTIFY

Chao Li <li.evan.chao@gmail.com>

View thread
From: Chao Li <li.evan.chao@gmail.com>
To: Joel Jacobson <joel@compiler.org>
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:44:44Z
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 Sep 26, 2025, at 17:32, Joel Jacobson <joel@compiler.org> wrote:
> 
> 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


I might miss the factor of holding an exclusive lock. I will revisit that part again.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/