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(dot)albe(at)cybertec(dot)at>
To: Charles Qi <qyqgpower(at)gmail(dot)com>
Cc: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org
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: 2025-08-13 05:14:48
Message-ID: 41cc55f13edfc22ab393fa27b54ca6b7fed32ee9.camel@cybertec.at
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, 2025-08-11 at 11:34 +0800, Charles Qi wrote:
> 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.

Still, you could explicitly lock the row in the trigger function with
a high enough lock level to avoid a multixact being created later on.

Yours,
Laurenz Albe

In response to

Browse pgsql-general by date

  From Date Subject
Next Message px shi 2025-08-13 05:48:05 Re: Questions about the continuity of WAL archiving
Previous Message Justin 2025-08-13 02:50:54 Re: Questions about the continuity of WAL archiving