public inbox for [email protected]  

help / color / mirror / Atom feed
From: Chao Li <[email protected]>
To: Joel Jacobson <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Thomas Munro <[email protected]>
Cc: pgsql-hackers <[email protected]>
Cc: Heikki Linnakangas <[email protected]>
Cc: Rishu Bagga <[email protected]>
Subject: Re: Optimize LISTEN/NOTIFY
Date: Mon, 29 Sep 2025 10:33:54 +0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CAK80=jhmE40KVqQ3ho37MArS7cAED1p9m7uikDxcnDmqdW7t8A@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<CA+hUKGLrMGkWDB0cwTa0RqD+AF7O-Ywgck8aVYKwOQnZgYRRug@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>


> On Sep 28, 2025, at 18:24, Joel Jacobson <[email protected]> wrote:
> 
>> 
>> I might miss the factor of holding an exclusive lock. I will revisit 
>> that part again.
> 
> I've re-read this entire thread, and I actually think my original
> approaches are more promising, that is, the
> 0001-optimize_listen_notify-v4.patch patch, doing multicast targeted
> signaling.
> 
> Therefore, merely consider the latest patch as PoC with some possible
> interesting ideas.
> 
> Before this patch, I had never used PostgreSQL's timeout mechanism
> before, so I didn't consider it when thinking about how to solve the
> remaining problems with 0001-optimize_listen_notify-v4.patch, which
> currently can't guarantee that all listening backends will eventually
> catch up, since it just kicks one of the most lagging ones, for each
> notification. This could be a problem in practise if there is a long
> period of time with no notifications coming in. Then some listening
> backends could end up not being signaled and would stay behind,
> preventing the queue tail from advancing.
> 
> I'm thinking maybe somehow we can use the timeout mechanism here, but
> I'm not sure how yet. Any ideas?
> 
> /Joel


Hi Joel,

I never had a concern about using the timeout mechanism. My comment was about enabling timeout duplicately.

I just revisited the code, now I agree that I was over-worried because I missed considering NotifyQueueLock. With the lock protection, a backend process’ QUEUE_BACKEND_WAKEUP_PENDING_FLAG won’t have race condition, then it should have no duplicate signals sending to the same backend process. Then in the backend process, you have “last_wakeup_start_time” that avoids duplicate timeout within a configured period, and you reset last_wakeup_start_time in asyncQueueReadAllNotifications() together with cleaning the QUEUE_BACKEND_WAKEUP_PENDING_FLAG.

So, overall v2 looks good to me.

One last tiny comment is about naming of last_wakeup_start_time. I think it can be renamed to “last_wakeup_time”. Because the variable just records when asyncQueueReadAllNotifications() last time called, there seems not a meaning of “start” involved.

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






reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Optimize LISTEN/NOTIFY
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox