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: <23347.1768587496@localhost>
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> <23347.1768587496@localhost>
Comments: In-reply-to Antonin Houska <ah@cybertec.at>
   message dated "Fri, 16 Jan 2026 19:18:16 +0100."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <85929.1768840279.1@localhost>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 19 Jan 2026 17:31:19 +0100
Message-ID: <85930.1768840279@localhost>
Archived-At: <https://www.postgresql.org/message-id/85930.1768840279%40localhost>
Precedence: bulk

Antonin Houska <ah@cybertec.at> wrote:

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

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

> The only problem is that the logical decoding system needs to wait durin=
g the
> setup for all the running transactions to finish. So if REPACK (CONCURRE=
NTLY)
> is already running, the next execution will not start until the first is=
 done.
> =

> However, that does not restrict the REPACK decoding workers from startin=
g.
> =

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

> > I don't think so. In case of non-MVCC safety we should see 0 or correc=
t sum. But script failed with 490588...
> > But should see 500500 (if I correctly calculated sum of numbers from 1=
 to 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 i=
ssue
> and even could reproduce some weird behavior using debugger. Since it al=
so
> affects logical replication, I'll provide more details (and hopefully pr=
opose
> a patch) in a separate thread early next week.

This is the report:

https://www.postgresql.org/message-id/85833.1768840165%40localhost

-- =

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