Message-ID: <2e0ffcb3a67e0ece4dd4de34d33541b12f4e78b7.camel@cybertec.at>
Subject: Re: Additional Notes
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: danielr@neophi.com, pgsql-docs@lists.postgresql.org
Date: Wed, 15 Nov 2023 19:05:05 +0100
In-Reply-To: 
 <170006991214.398197.16221983243746809180@wrigleys.postgresql.org>
References: 
	<170006991214.398197.16221983243746809180@wrigleys.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/2e0ffcb3a67e0ece4dd4de34d33541b12f4e78b7.camel%40cybertec.at>
Precedence: bulk

On Wed, 2023-11-15 at 17:38 +0000, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
>=20
> Page: https://www.postgresql.org/docs/16/sql-notify.html
> Description:
>=20
> It would be good to add to the notes section that use of NOTIFY especiall=
y
> within a TRIGGER requires an AccessExclusiveLock which may cause performa=
nce
> 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