Re: BUG #17212: pg_amcheck fails on checking temporary relations

> On Oct 4, 2021, at 4:10 PM, Peter Geoghegan <pg(at)bowt(dot)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