Mihail Nikalayeu <[email protected]> wrote: > On Mon, Apr 27, 2026 at 6:25 AM Amit Kapila <[email protected]> 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
