From: Antonin Houska <ah@cybertec.at>
To: shihao zhong <zhong950419@gmail.com>
cc: Manu <manuelreyesbravo@gmail.com>,
    pgsql-hackers@lists.postgresql.org
Subject: Re: REPACK enhancements
In-reply-to: 
 <CAGRkXqQALou-8wV8MTG-BUhz2LGZuPn61mU5VE4hW8rTBkVd0w@mail.gmail.com>
References: 
 <CAGRkXqRX2baaDYHjHLK511vL3kuT8qmZRXbx+bgHCPcgyKsEjw@mail.gmail.com>
 <179004809718.4166269.6878292164216131831@gmail.com>
 <28303.1790158015@localhost> <163579.1790787537@localhost>
 <CAGRkXqQALou-8wV8MTG-BUhz2LGZuPn61mU5VE4hW8rTBkVd0w@mail.gmail.com>
Comments: In-reply-to shihao zhong <zhong950419@gmail.com>
   message dated "Wed, 30 Sep 2026 21:28:01 -0600."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <28203.1790879346.1@localhost>
Date: Thu, 01 Oct 2026 20:29:06 +0200
Message-ID: <28204.1790879346@localhost>
Archived-At: 
 <https://www.postgresql.org/message-id/28204.1790879346%40localhost>
Precedence: bulk

shihao zhong <zhong950419@gmail.com> wrote:

> The compute_new_xmax_infomask() Assert is easy to hit. The
> AccessExclusiveLock in rebuild_relation_finish_concurrent() assigns an
> XID, so any UPDATE or DELETE committed while REPACK waits for it fails
> on replay. The attached spec does it every time.

Ah, I see, the assertion itself is wrong. Thanks.

> If you give the new counter a slot that index builds don't write,
> like 13, 0008 does not have to depend on 6958.

It'd work, but if [1] gets merged, this workaround would be confusing.

[1] https://commitfest.postgresql.org/patch/6958/

-- 
Antonin Houska
Web: https://www.cybertec-postgresql.com