Hello Mark, Peter, Robert,
05.10.2021 20:22, Peter Geoghegan пишет:
> On Tue, Oct 5, 2021 at 10:03 AM Mark Dilger
> <mark.dilger@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
