From: Antonin Houska <ah@cybertec.at>
To: Mihail Nikalayeu <mihailnikalayeu@gmail.com>
cc: Amit Kapila <amit.kapila16@gmail.com>,
    Andres Freund <andres@anarazel.de>,
    Alvaro Herrera <alvherre@alvh.no-ip.org>,
    Srinath Reddy Sadipiralla <srinath2133@gmail.com>,
    Matthias van de Meent <boekewurm+postgres@gmail.com>,
    Pg Hackers <pgsql-hackers@lists.postgresql.org>,
    Robert Treat <rob@xzilla.net>
Subject: Re: Adding REPACK [concurrently]
In-reply-to: 
 <CADzfLwWnbKcb3v8sStdgNE=WNc3uUqx5SiS4zftX2UaEfNzG5w@mail.gmail.com>
References: 
 <CAA4eK1Jg21ODQ7fS2fvN5W_S5kDRhAP5inj3XMRQaa=s-GbYhw@mail.gmail.com>
 <202604071230.b5axxf3qna3m@alvherre.pgsql>
 <cdgw4sbbfcgk6du3iv54r2dgiy4tfywoklbotlmj4irxavdcr3@glxfw5jj277q>
 <227677.1775576304@localhost>
 <pveffyxhnuurhb44uzqlwo3rkyzorkfh2rot7uwzlf2axhfvbp@7nrs2omysxkc>
 <CAA4eK1JhuT5fyTosWDZ+Pgs+j7xEjObTyRMn80uNKgi_ivqHbw@mail.gmail.com>
 <CADzfLwWnbKcb3v8sStdgNE=WNc3uUqx5SiS4zftX2UaEfNzG5w@mail.gmail.com>
Comments: In-reply-to Mihail Nikalayeu <mihailnikalayeu@gmail.com>
   message dated "Thu, 30 Apr 2026 13:24:41 +0200."
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Mon, 04 May 2026 15:24:49 +0200
Message-ID: <85813.1777901089@localhost>
Archived-At: 
 <https://www.postgresql.org/message-id/85813.1777901089%40localhost>
Precedence: bulk

Mihail Nikalayeu <mihailnikalayeu@gmail.com> wrote:

> On Mon, Apr 27, 2026 at 6:25=E2=80=AFAM Amit Kapila <amit.kapila16@gmail.=
com> wrote:
> > Alvaro, others, what is your take on this?
>=20
> I agree with you here - we should AT LEAST make that an ERROR instead
> of an assert and also check it during cache access (not only during
> the scan because of cache misses).
> But I think it will still be fragile in case of some extensions installed.
>=20
> Anyway... We also have an issue with correctness right now.
>=20
> I took the old stress test from [0] (the first two) and it fails now,
> even with the fix from [1] ("Possible premature SNAPBUILD_CONSISTENT
> with DB-specific running_xacts").
>=20
> It looks like [1] fixes 008_repack_concurrently.pl, but
> 007_repack_concurrently.pl fails anyway, including
>=20
>      pgbench: error: client 1 script 0 aborted in command 10 query 0:
> ERROR:  could not create unique index "tbl_pkey_repacknew"
>      # DETAIL:  Key (i)=3D(383) is duplicated.
> and
>      'pgbench: error: pgbench:client 23 script 0 aborted in command 31
> query 0: ERROR:  division by zero
>=20
> Last one is not MVCC-related; you can see from the logs that it
> performs something like SELECT (509063) / 0 when the table sum
> changes.
>=20
> Setting need_shared_catalogs =3D true make them pass, so something is
> wrong with its correctness.

Thanks for testing again. Whether we keep the "database specific slots" or
not, it'd be good to know what exactly the reason of these errors is. I won=
der
if the feature just exposes a problem that remains shadowed otherwise, due =
to
the contention on replication slot. I'm going to investigate.

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