Hello Mark, Peter, Robert, 05.10.2021 20:22, Peter Geoghegan пишет: > On Tue, Oct 5, 2021 at 10:03 AM Mark Dilger > <mark.dil...@enterprisedb.com> wrote: >> I took no offense. Actually, I owe you a thank-you for having put so much >> effort into debating the behavior with me. I think the patch to fix bug >> #17212 will be better for it. > Glad that you think so. And, thanks for working on the issue so promptly. > > This was a question of fundamental definitions. Those are often very tricky. Thanks for the discussion and fixing the issues! (I haven't found the latest fix in the thread yet, but I agree with the approach.)
I think that ideally pg_amcheck should not fail on a live database, that does not contain corrupted data, and should not affect the database usage by other users (as it's "only a check"). So for example, pg_amcheck should run successfully in parallel with `make installcheck` and should not cause any of the tests fail. (There could be nuances with, say, volatile functions called by the index expressions, but in general it could be possible.) I tried to run the following script: (for i in `seq 100`; do echo "=== iteration $i ===" >>pg_amcheck.log; pg_amcheck -a --install-missing --heapallindexed --rootdescend --progress >>pg_amcheck.log 2>&1 || echo "FAIL" >>pg_amcheck.log; done) & make installcheck And got several deadlocks again (manifested by some tests failing) and also "ERROR: could not open relation with OID xxxx" - that could be considered as a transition state (it is possible without locking), that cause pg_amcheck to report an overall error. Best regards, Alexander
