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-26T02:26:37Z
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 05:13, Joel Jacobson <joel@compiler.org> wrote:
> 
> Hmm, I don't see how duplicate timeout could happen?
> 
> Once we decide to defer the wakeup, wakeup_pending_flag remains set,
> which avoids further signals from notifiers, so I don't see how we could
> re-enter ProcessIncomingNotify(), since notifyInterruptPending is reset
> when ProcessIncomingNotify() is called, and notifyInterruptPending is
> only set when a signal is received (or set directly when in same
> process).
> 


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.

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