Re: Optimize LISTEN/NOTIFY

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>

To: "Joel Jacobson" <joel@compiler.org>

Cc: "Chao Li" <li.evan.chao@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>

Date: 2025-11-25T20:17:28Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Optimize LISTEN/NOTIFY via shared channel map and direct advancement.
- 282b1cde9ded 19 (unreleased) landed
Fix incorrect logic for caching ResultRelInfos for triggers
- 39dcfda2d23a 19 (unreleased) cited

"Joel Jacobson" <joel@compiler.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.)

			regards, tom lane