Re: Adding REPACK [concurrently]

Hello!

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.

P.S.
I think it is good idea to add these stress tests to the source tree,
perhaps with some kind PG_TEST_EXTRA=stress (as done in [1]).

[0]: https://www.postgresql.org/message-id/flat/CADzfLwUitd5J17O9FUxNGrZBurOpL6n%2BtnS6dgArXi-i9DNxhg%40mail.gmail.com#c5945a539400676cdfd72eec6c101710
[1]: https://www.postgresql.org/message-id/flat/CAHg%2BQDcQak4jx_6X2_Ws98rzG%3DxBARLjqm_%3D56wTRUtNsY4DZQ%40mail.gmail.com
[2]: https://www.postgresql.org/message-id/flat/CADzfLwWC%2BKxYWb-2QotWaz-q1LK8koLNVUR1Q8obAtt%2BR_sORA%40mail.gmail.com#c8435a284f8893bbc1a891c56be5e158