Our callout use of NOTIFY within a TRIGGER may be tangential to the root
cause. What we wanted to call out is that neither the NOTIFY page or the
https://www.postgresql.org/docs/16/explicit-locking.html page mention that
NOTIFY uses an AccessExclusiveLock.

-- Daniel R. <dani...@neophi.com> [http://danielr.neophi.com/]


On Wed, Nov 15, 2023 at 1:05 PM Laurenz Albe <laurenz.a...@cybertec.at>
wrote:

> On Wed, 2023-11-15 at 17:38 +0000, PG Doc comments form wrote:
> > The following documentation comment has been logged on the website:
> >
> > Page: https://www.postgresql.org/docs/16/sql-notify.html
> > Description:
> >
> > It would be good to add to the notes section that use of NOTIFY
> especially
> > within a TRIGGER requires an AccessExclusiveLock which may cause
> performance
> > issues. Old thread for reference:
> > https://www.postgresql.org/message-id/3598.1363354686%40sss.pgh.pa.us
>
> I don't see what this has to do with triggers.  Even deferred triggers run
> *before* this notify lock is taken.
>
> The only possibility I see for such a lock to be held for a long time is if
> COMMIT spends a long time waiting for a reply from a synchronous standby
> server.  Is that your problem?
>
> I don't think that would require special documentation, because if your
> synchronous standby does not respond in time, you normally have worse
> problems than NOTIFY performance.
>
> Yours,
> Laurenz Albe
>

Reply via email to