Re: Optimize LISTEN/NOTIFY - Mailing list pgsql-hackers

From Joel Jacobson
Subject Re: Optimize LISTEN/NOTIFY
Date
Msg-id d29ae0a8-b28c-4450-bd9f-c56657e57f45@app.fastmail.com
Whole thread Raw
In response to Re: Optimize LISTEN/NOTIFY  (Chao Li <li.evan.chao@gmail.com>)
Responses Re: Optimize LISTEN/NOTIFY
List pgsql-hackers
On Tue, Oct 28, 2025, at 07:46, Chao Li wrote:
>>> But anyway, we should run some load tests to verify every solution to 
>>> see how much they really improve. Do you already have or plan to work 
>>> on a load test script?
>> 
>> Yes, I'm currently working on a combined benchmark / correctness test suite.
>> 
>
> Cool. Then we can run the benchmark and decide.

I found a concurrency bug in v21 that could cause missed wakeup when a
backend would UNLISTEN on the last channel, which called
asyncQueueUnregister, and if wakeupPending was at that time already set,
then it wouldn't get reset, since in ProcessIncomingNotify we return
early if (listenChannels == NIL), so we would never clear wakeupPending
which happens in asyncQueueReadAllNotifications.

Fixed by clearing wakeupPending in asyncQueueUnregister:

@@ -1597,6 +1597,7 @@ asyncQueueUnregister(void)
    /* Mark our entry as invalid */
    QUEUE_BACKEND_PID(MyProcNumber) = InvalidPid;
    QUEUE_BACKEND_DBOID(MyProcNumber) = InvalidOid;
+   QUEUE_BACKEND_WAKEUP_PENDING(MyProcNumber) = false;
    /* and remove it from the list */
    if (QUEUE_FIRST_LISTENER == MyProcNumber)
        QUEUE_FIRST_LISTENER = QUEUE_NEXT_LISTENER(MyProcNumber);

/Joel
Attachment

pgsql-hackers by date:

Previous
From: "Daniel Verite"
Date:
Subject: Re: [PATCH] Fix ICU strength not being honored in collation rules
Next
From: Joe Conway
Date:
Subject: Re: contrib/sepgsql regression tests have been broken for months