public inbox for [email protected]  

help / color / mirror / Atom feed

From: Charles Qi <[email protected]>
To: Laurenz Albe <[email protected]>
Cc: Adrian Klaver <[email protected]>
Cc: [email protected]
Subject: Re: When UPDATE a row in a table with BEFORE ROW UPDATE trigger, the XMAX of new tuple is set to current XID
Date: Mon, 11 Aug 2025 11:34:08 +0800
Message-ID: <CAEawgc++MEp-Cgrpg0NR+9hg4ZhzKPWdnf9pPvheXTrew=kkJA@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CAEawgcJN2V0MTzZu5gi=csNapnJzogxJJqUFSphu6r=OXjorng@mail.gmail.com>
	<[email protected]>
	<CAEawgcLdD3-4Co8mrR7UaXJLGgBwSecUs-1QxyY3VoJzN9bnmg@mail.gmail.com>
	<[email protected]>

On Mon, Aug 11, 2025 at 3:34 AM Laurenz Albe <[email protected]> wrote:
>
> On Fri, 2025-08-08 at 09:20 +0800, Charles Qi wrote:
> > Let me clarify the question, when the BEFORE ROW UPDATE trigger is presented
> > 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).
>

With or without the trigger, the row gets locked and unlocked while
the update is doing its thing.
The problem here is that HEAP_XMAX_KEYSHR_LOCK and XMAX are set with
the trigger even if the update transaction is finished, while both are
not set without the trigger.

> > 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

The piling up of multixacts are related to the performance topic,
which is not in the scope of this mail.

The trigger function in example is doing nothing but return new, the
row is actually locked by the trigger itself (trigger.c >
ExecBRUpdateTriggers > GetTupleForTrigger)
You mentioned a very important behavior:
> A multixact is only necessary
> if a subtransaction needs to take a stronger lock on the row than what
> was there before.
We are doing two no key updates in example, and should not need a
stronger lock on the same row.

view thread (5+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: When UPDATE a row in a table with BEFORE ROW UPDATE trigger, the XMAX of new tuple is set to current XID
  In-Reply-To: <CAEawgc++MEp-Cgrpg0NR+9hg4ZhzKPWdnf9pPvheXTrew=kkJA@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox