Re: Optimize LISTEN/NOTIFY

On Wed, Nov 5, 2025 at 12:22 PM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
>
>
>
> > On Nov 2, 2025, at 04:41, Arseniy Mukhin <arseniy(dot)mukhin(dot)dev(at)gmail(dot)com> wrote:
> >
> > This condition seems to be redundant. I would say it should always be
> > true, otherwise it would mean that somebody allowed the listener to
> > skip our notification.
>
> Hi Arseniy,
>

Hi Chao,

> Did you read the example I explained in my previous email?
>

Yes, I read it. Thank you for the example. It shows the case where we
can fail to apply 'direct advancement'. I think there are several
cases where it can happen. IIUC all such cases are about lagging
listeners that failed to catch up with the head before the notifier
tries to apply 'direct advancement' to them. Your example is about
listeners that finished reading but didn't update their positions
because they were stuck on the lock. I think it is also possible that
the listener can be in the process of reading or even didn't start
reading at all (for example listener backend is in the active
transaction at the moment). In these cases we also can't apply direct
advancement. Don't know if some of these examples are more important,
maybe some of them can be met more frequently.

I think the current version of 'direct advancement' will work good for
'sleepy' listeners, but probably can be not very efficient for
listeners that get notifications frequently, don't know. But maybe
it's ok, we have optimization that sometimes works and have a quite
simple implementation.

Best regards,
Arseniy Mukhin