shihao zhong <[email protected]> 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
