Re: Adding REPACK [concurrently]

Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com> wrote:

> On Mon, Apr 27, 2026 at 6:25 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > Alvaro, others, what is your take on this?
>
> 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.
>
> Anyway... We also have an issue with correctness right now.
>
> 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").
>
> It looks like [1] fixes 008_repack_concurrently.pl, but
> 007_repack_concurrently.pl fails anyway, including
>
> pgbench: error: client 1 script 0 aborted in command 10 query 0:
> ERROR: could not create unique index "tbl_pkey_repacknew"
> # DETAIL: Key (i)=(383) is duplicated.
> and
> 'pgbench: error: pgbench:client 23 script 0 aborted in command 31
> query 0: ERROR: division by zero
>
> 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.
>
> Setting need_shared_catalogs = 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 wonder
if the feature just exposes a problem that remains shadowed otherwise, due to
the contention on replication slot. I'm going to investigate.

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