From: Antonin Houska <ah@cybertec.at>
To: Mihail Nikalayeu <mihailnikalayeu@gmail.com>
cc: Alvaro Herrera <alvherre@alvh.no-ip.org>,
    Pg Hackers <pgsql-hackers@lists.postgresql.org>,
    Robert Treat <rob@xzilla.net>
Subject: Re: Adding REPACK [concurrently]
In-reply-to: <CADzfLwU78as45To9a=-Qkr5jEg3tMxc5rUtdKy2MTv4r_SDGng@mail.gmail.com>
References: <202512151349.vlq3mpfniyk3@alvherre.pgsql> <11247.1767609087@localhost> <11558.1767609632@localhost> <141054.1767891540@localhost> <CADzfLwU-OmxW3t3AoQo9=K7uq4G1yZ-txcetzW3jbcVxV_pJew@mail.gmail.com> <137668.1768235610@localhost> <CADzfLwUJSHKGxYw+vMUZ_Hr2YeuxO2Q5w13HKgUUN1725tjY5Q@mail.gmail.com> <CADzfLwU78as45To9a=-Qkr5jEg3tMxc5rUtdKy2MTv4r_SDGng@mail.gmail.com>
Comments: In-reply-to Mihail Nikalayeu <mihailnikalayeu@gmail.com>
   message dated "Mon, 12 Jan 2026 21:54:56 +0300."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <35685.1768495019.1@localhost>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 15 Jan 2026 17:36:59 +0100
Message-ID: <35686.1768495019@localhost>
Archived-At: <https://www.postgresql.org/message-id/35686.1768495019%40localhost>
Precedence: bulk

Mihail Nikalayeu <mihailnikalayeu@gmail.com> wrote:

> Also, there are some crashes of stress tests for v30 (for both single sn=
apshot and multiple snapshot versions).
> =

> ---------------------
> =

> Looks like something is leaking, but not sure.
> =

> https://cirrus-ci.com/task/5577209672368128?logs=3Dtest_world#L277 (mult=
iple snapshots)
> https://cirrus-ci.com/task/6439044873191424 (without multiple snapshots)

As the test runs pgbench with --client=3D30 and the default value of
max_worker_processes is 8, I'm not sure this is a leak. I've increased thi=
s
parameter I couldn't see the error anymore.

> This one showed something goes wrong, the sum of the table is broken. It=
 may be 0 because non-MVCC safe, but I checked the logs:
> =

> 2026-01-12 18:41:11.656 UTC client backend[76247] 007_repack_concurrentl=
y.pl LOG:  statement: SELECT (490588) / 0;

I agree that this is due to the missing MVCC safety feature. I commented t=
hat
check in the script for now.

Besides that, I saw some deadlocks. I think this was due to the fact that
multiple rows are updated per transaction, and that the keys are random, s=
o it
can happen that two transactions try to update the same rows in different
order. I increased the number of rows in the test table to 10000 and don't=
 see
the deadlocks anymore.

> backend[54349] 007_repack_concurrently.pl ERROR:  could not create uniqu=
e index "tbl_pkey_repacknew"
> 2026-01-12 18:41:12.477 UTC client backend[54349] 007_repack_concurrentl=
y.pl DETAIL:  Key (i)=3D(942) is duplicated.
> 2026-01-12 18:41:12.477 UTC client backend[54349] 007_repack_concurrentl=
y.pl STATEMENT:  REPACK (CONCURRENTLY) tbl;

This is tricky. I could reproduce the problem on my FreeBSD box a few time=
s,
never on Linux (no idea if the OS makes the difference since HW is also qu=
ite
different, but CI also seemed to fail more often on FreeBSD.)

Something seems to be wrong about UPDATE, but I'm failing to understand ho=
w it
could relate to REPACK. This is an example of a duplicate value i=3D6118

SELECT i, j, xmin, xmax, ctid FROM tbl WHERE i=3D6118;
  i   |   j    |  xmin  |  xmax  |  ctid   =

------+--------+--------+--------+---------
 6118 | 445435 | 102317 | 103702 | (1,216)
 6118 | 391135 | 103702 |      0 | (56,62)

According to log, xid=3D102317 is the transaction used by REPACK and xid=3D=
103702
one of the test. pageinspect shows that the old version has not only
HEAP_XMIN_COMMITTED in t_infomask, but also HEAP_XMAX_INVALID.

So far I could not reproduce the duplicities with the REPACK (CONCURRENTLY=
)
command commented out in the test script, but that does not prove much (ev=
en
with REPACK, not every run fails). Also I noticed that REPACK incorrectly =
sets
cmin/cmax to 1 instead of 0 and it needs to be fixed, but I have no idea w=
hy
this bug should cause exactly this weird behavior.

I even added quite a few logging messages to reveal where in the code the
HEAP_XMAX_INVALID flag is set for particular ctid, but after a failure I c=
ould
not find the message for the problematic tuples. Ideas are appreciated.

-- =

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