Re: Adding REPACK [concurrently]

Mihail Nikalayeu <mihailnikalayeu@gmail.com> wrote:

> On Mon, Apr 27, 2026 at 6:25 AM Amit Kapila <amit.kapila16@gmail.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