> On Oct 4, 2021, at 4:10 PM, Peter Geoghegan <pg@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
towonder if that was the right way to go. I certainly don't assume pg_amcheck is correct by definition. I already
posteda patch for the temporary tables bug upthread having never argued that it was anything other than a bug. I also
wrotea patch for verify_heapam to fix the problem with unlogged tables on standbys, and was developing a test for that,
whenI got your email. I'm not arguing against that being a bug, either. Hopefully, I can get that properly tested and
postit 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'tsee 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
becausethey see error messages in the logs during a long running reindex command, and are curious if the index so
generatedis corrupt. You can't assume the user knows the index is still being reindexed. If the last message logged
wassome time ago, they might assume the process has finished. So something other than a silent success is needed to
letthem know what is going on.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company