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: <CADzfLwWQRAqi1EQrKFiTgXJsdz_3ZFAWkto97hsYb-bMcpwuwg@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> <35686.1768495019@localhost> <CADzfLwWQRAqi1EQrKFiTgXJsdz_3ZFAWkto97hsYb-bMcpwuwg@mail.gmail.com>
Comments: In-reply-to Mihail Nikalayeu <mihailnikalayeu@gmail.com>
   message dated "Thu, 15 Jan 2026 20:05:02 +0300."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <23346.1768587496.1@localhost>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 16 Jan 2026 19:18:16 +0100
Message-ID: <23347.1768587496@localhost>
Archived-At: <https://www.postgresql.org/message-id/23347.1768587496%40localhost>
Precedence: bulk

Mihail Nikalayeu <mihailnikalayeu@gmail.com> wrote:

>Antonin Houska <ah@cybertec.at>:
>> =

>> 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 =
this
>> parameter I couldn't see the error anymore.
> =

> Hm, as far as I remember only single repack may be executed in test (bec=
ause
> of locking on test itself and also REPACK).

The only problem is that the logical decoding system needs to wait during =
the
setup for all the running transactions to finish. So if REPACK (CONCURRENT=
LY)
is already running, the next execution will not start until the first is d=
one.

However, that does not restrict the REPACK decoding workers from starting.

>>  I agree that this is due to the missing MVCC safety feature. I comment=
ed that
>>  check in the script for now.
> =

> I don't think so. In case of non-MVCC safety we should see 0 or correct =
sum. But script failed with 490588...
> But should see 500500 (if I correctly calculated sum of numbers from 1 t=
o 1000)...

I was referring to your statement "It may be 0 because non-MVCC
safe". Regarding the non-zero values, I think I finally understand the iss=
ue
and even could reproduce some weird behavior using debugger. Since it also
affects logical replication, I'll provide more details (and hopefully prop=
ose
a patch) in a separate thread early next week.

In short, it looks like (hopefully very) rare race condition, such that th=
e
snapshot builder can build the initial snapshot before all the commits hav=
e
been recorded in CLOG. When that happens, visibility checks don't work
correctly.

-- =

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