public inbox for [email protected]  

help / color / mirror / Atom feed

From: Joel Jacobson <[email protected]>
To: Tom Lane <[email protected]>
Cc: Chao Li <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: Optimize LISTEN/NOTIFY
Date: Tue, 25 Nov 2025 21:14:12 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CAK80=jhmE40KVqQ3ho37MArS7cAED1p9m7uikDxcnDmqdW7t8A@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<CA+hUKGLrMGkWDB0cwTa0RqD+AF7O-Ywgck8aVYKwOQnZgYRRug@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CAFY6G8dap-bCnAnMG-2Gzew8yv2Vbi9gsx9+yszKMmd57ygfvA@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CAE7r3MLivh1sHWF06hrVXkiQbw-KChPcQsh+9CheXprm5vRVMQ@mail.gmail.com>
	<14865EB6-0BF4-462B-9072-10BDAC10C0>
	<[email protected]>

On Thu, Nov 20, 2025, at 21:26, Tom Lane wrote:
> So I think there needs to be a serious effort made to move as
> much as we possibly can of the potentially-risky stuff into
> PreCommit_Notify.  In particular I think we ought to create
> the shared channel hash entry then, and even insert our PID
> into it.  We could expand the listenersArray entries to include
> both a PID and a boolean "is it REALLY listening?", and then
> during Exec_ListenCommit we'd only be required to find an
> entry we already added and set its boolean, so there's no OOM
> hazard.  Possibly do something similar with the local
> listenChannelsHash, so as to remove that possibility of OOM
> failure as well.
>
> (An alternative design could be to go ahead and insert our
> PID during PreCommit_Notify, and just tolerate the small
> risk of getting signaled when we didn't need to be.  But
> then we'd need some mechanism for cleaning out the bogus
> entry during AtAbort_Notify.)

[...back from a little detour with new insights...]

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.

This way, cleanup for the rare edge-case when we did PreCommit_Notify
followed by AtAbort_Notify, seems simple; we just need to go through all
entires and delete those where current=false, since those entries were
newly added by PreCommit_Notify, i.e. we were not listening to those
channels since before.  Probably also setting a flag in
PreCommit_Notify, so that we only need to do cleanup in AtAbort_Notify
if we actually hit PreCommit_Notify.

I haven't implemented this yet, but I have a good feeling about this
approach.  Just wanted to share the plan before I start working, in case
anyone see any flaw with it, or see a better approach.

/Joel

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: Optimize LISTEN/NOTIFY
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox