Re: Optimize LISTEN/NOTIFY

From: "Joel Jacobson" <joel(at)compiler(dot)org>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Chao Li" <li(dot)evan(dot)chao(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Optimize LISTEN/NOTIFY
Date: 2025-12-27 12:40:29
Message-ID: dc42020c-c717-4870-8997-b9f64c9a381e@app.fastmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Dec 26, 2025, at 21:12, Joel Jacobson wrote:
> On Tue, Nov 25, 2025, at 21:17, Tom Lane wrote:
>> "Joel Jacobson" <joel(at)compiler(dot)org> writes:
>>> It looks to me like it would be best with two boolean fields; one
>>> boolean to stage the updates during PreCommit_Notify, that each
>>> pendingActions could flip back and forth, and another boolean that
>>> represents the current value, which we would overwrite with the staged
>>> value during AtCommit_Notify.
>>
>> +1, I had a feeling that a single boolean wouldn't quite do it.
>> (There are various ways we could define the states, but what
>> you say above seems pretty reasonable.)
>
> I've implemented the two boolean approach and think it's good.
>
> The signals arrays are now preallocated during PreCommit_Notify.
>
> More details in the patch message under "Two-phase staging pattern".

New version with some fixes.

I should have mentioned that v31 is based on v28 (v29 and v30 were discarded).

Here is also a write-up of changes from v28 to v31:

0001: No changes.

0002:

* To avoid post-commit OOM hazards, we now allocate hash table entries
during PreCommit_Notify. Each listener entry has two boolean flags;
staged and current. For each LISTEN/UNLISTEN action the staged flag
is set/unset during PreCommit_Notify. The last action's staged value
per channel is then copied from staged to current during
AtCommit_Notify.

* On abort, AtAbort_Notify reverts staged changes.

* The signal arrays are now preallocated during PreCommit_Notify.

* Renamed Exec_UnlistenAllCommit to CleanupListenersOnExit for the
exit-handler path, since it has different semantics (unconditional
removal rather than staged/current handling).

In case someone has already started reviewing v31,
these are the changes I made in v32:

0001:

* Added test: Check UNLISTEN * cancels a LISTEN in the same transaction

0002:
* Fixed initialization of QueueBackendStatus fields, corrected the
LISTEN + UNLISTEN same-transaction case, restructured AtAbort_Notify
to mirror AtCommit_Notify, and added a guard for OOM during staging.

/Joel

Attachment Content-Type Size
0001-optimize_listen_notify-v32.patch application/octet-stream 9.9 KB
0002-optimize_listen_notify-v32.patch application/octet-stream 54.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2025-12-27 13:18:56 Re: Limit memory usage by postgres_fdw batches
Previous Message Laurenz Albe 2025-12-27 12:15:58 Re: Get rid of "Section.N.N.N" on DOCs