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
