On Sep 28, 2025, at 18:24, Joel Jacobson <joel@compiler.org> 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 originalapproaches are more promising, that is, the0001-optimize_listen_notify-v4.patch patch, doing multicast targetedsignaling.Therefore, merely consider the latest patch as PoC with some possibleinteresting ideas.Before this patch, I had never used PostgreSQL's timeout mechanismbefore, so I didn't consider it when thinking about how to solve theremaining problems with 0001-optimize_listen_notify-v4.patch, whichcurrently can't guarantee that all listening backends will eventuallycatch up, since it just kicks one of the most lagging ones, for eachnotification. This could be a problem in practise if there is a longperiod of time with no notifications coming in. Then some listeningbackends 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, butI'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/
