Message-ID: <93c76ed6cabcd32993203f03c7ce4fc88b20c087.camel@cybertec.at>
Subject: Re: When UPDATE a row in a table with BEFORE ROW UPDATE trigger,
 the XMAX of new tuple is set to current XID
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Charles Qi <qyqgpower@gmail.com>, Adrian Klaver
 <adrian.klaver@aklaver.com>
Cc: pgsql-general@lists.postgresql.org
Date: Sun, 10 Aug 2025 21:34:19 +0200
In-Reply-To: <CAEawgcLdD3-4Co8mrR7UaXJLGgBwSecUs-1QxyY3VoJzN9bnmg@mail.gmail.com>
References: 
	<CAEawgcJN2V0MTzZu5gi=csNapnJzogxJJqUFSphu6r=OXjorng@mail.gmail.com>
	 <1f99e5c1-a203-4441-aa5c-33a3baaf852c@aklaver.com>
	 <CAEawgcLdD3-4Co8mrR7UaXJLGgBwSecUs-1QxyY3VoJzN9bnmg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.56.2 (3.56.2-1.fc42) 
MIME-Version: 1.0
Archived-At: <https://www.postgresql.org/message-id/93c76ed6cabcd32993203f03c7ce4fc88b20c087.camel%40cybertec.at>
Precedence: bulk

On Fri, 2025-08-08 at 09:20 +0800, Charles Qi wrote:
> Let me clarify the question, when the BEFORE ROW UPDATE trigger is presen=
ted
> Q. Why do we need to set the XMAX of the new tuple to the current xid?

Because the row gets locked, I'd say (without looking at your example).

> which risks piling up multixacts quickly in savepoint/exception block
> scenarios.

Why is that a problem for you?

Perhaps the trigger could use SELECT ... FOR ... to lock the row in the
strongest level your transaction needs.  A multixact is only necessary
if a subtransaction needs to take a stronger lock on the row than what
was there before.

Yours,
Laurenz Albe