Thread

  1. Re: Optimize LISTEN/NOTIFY

    Joel Jacobson <joel@compiler.org> — 2025-11-25T20:14:12Z

    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