Feedback-ID: i76984098:Fastmail
Message-ID: <1f99e5c1-a203-4441-aa5c-33a3baaf852c@aklaver.com>
Date: Wed, 6 Aug 2025 11:22:28 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: When UPDATE a row in a table with BEFORE ROW UPDATE trigger, the
 XMAX of new tuple is set to current XID
To: Charles Qi <qyqgpower@gmail.com>, pgsql-general@lists.postgresql.org
References: <CAEawgcJN2V0MTzZu5gi=csNapnJzogxJJqUFSphu6r=OXjorng@mail.gmail.com>
Content-Language: en-US
From: Adrian Klaver <adrian.klaver@aklaver.com>
In-Reply-To: <CAEawgcJN2V0MTzZu5gi=csNapnJzogxJJqUFSphu6r=OXjorng@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/1f99e5c1-a203-4441-aa5c-33a3baaf852c%40aklaver.com>
Precedence: bulk

On 8/6/25 05:37, Charles Qi wrote:
> And if we do the updates in multiple subtransactions, multixact will be 
> created, which is not created when the BEFORE ROW UPDATE trigger is absent.
> 
> Is this behavior by design? If so, what is the purpose for the behavior?

I would say this is by design. My reasoning is that the savepoints are 
essentially rollback points and the state of the tuple would need to be 
saved for each potential rollback. Hence a different transaction id for 
each savepoint.

> 
> Tested version:
> PostgreSQL 14.18 (Ubuntu 14.18-0ubuntu0.22.04.1) on x86_64-pc-linux-gnu, 
> compiled by gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, 64-bit
> 
> The attached file reproduce.sql can be used to reproduce the behavior.


-- 
Adrian Klaver
adrian.klaver@aklaver.com