Re: REPACK enhancements

From: Manu <manuelreyesbravo(at)gmail(dot)com>
To: Antonin Houska <ah(at)cybertec(dot)at>
Cc: shihao zhong <zhong950419(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: REPACK enhancements
Date: 2026-11-14 01:23:07
Message-ID: 179461938749.1794772.16290685916698475395@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Antonin,

On Wed, Nov 11, 2026 at 2:26 PM Antonin Houska <ah(at)cybertec(dot)at> wrote:
> I don't really understand why 'xmax' should be involved. The original
> assertion checks exactly whether 'add_to_max' is the "current transaction" and
> I tried to disable it exactly when the function is called by REPACK (to replay
> data changes). However, 'xmax' can be invalid even in cases unrelated to
> REPACK (i.e. when doing "regular" UPDATE / DELETE). Thus what you propose
> makes the assertion a bit less useful.

You're right. I used xmax because the replay always gets here with
xmax invalid, so the code below never looks at the current
transaction. But a regular UPDATE or DELETE usually gets here the
same way, so for them the assertion would check nothing, and my
"keeps the old check" was wrong. Leaving it commented out, as in v05,
is fine with me.

Regards,
Manu

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Manu 2026-11-14 01:28:33 Re: Make COPY format extendable: Extract COPY TO format implementations
Previous Message Manu 2026-11-14 01:12:56 Re: pgsql: Don't trust NOT NULL on virtual generated columns of partitioned