> On Oct 4, 2021, at 4:10 PM, Peter Geoghegan <p...@bowt.ie> wrote:
>
> And I don't understand why you think that clearly-accidental
> implementation details (really just bugs) should be treated as
> axiomatic truths about how pg_amcheck must work. Should we now "fix"
> pg_dump so that it matches pg_amcheck?
>
> All of the underlying errors are cases that were clearly intended to
> catch user error -- every single one. But apparently pg_amcheck is
> incapable of error, by definition. Like HAL 9000.
On the contrary, I got all the way finished writing a patch to have pg_amcheck
do as you suggest before it dawned on me to wonder if that was the right way to
go. I certainly don't assume pg_amcheck is correct by definition. I already
posted a patch for the temporary tables bug upthread having never argued that
it was anything other than a bug. I also wrote a patch for verify_heapam to
fix the problem with unlogged tables on standbys, and was developing a test for
that, when I got your email. I'm not arguing against that being a bug, either.
Hopefully, I can get that properly tested and post it before too long.
I am concerned about giving the user the false impression that an index (or
table) was checked when it was not. I don't see the logic in
pg_amcheck -i idx1 -i idx2 -i idx3
skipping all three indexes and then reporting success. What if the user
launches the pg_amcheck command precisely because they see error messages in
the logs during a long running reindex command, and are curious if the index so
generated is corrupt. You can't assume the user knows the index is still being
reindexed. If the last message logged was some time ago, they might assume the
process has finished. So something other than a silent success is needed to
let them know what is going on.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
