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

> On Oct 11, 2021, at 5:37 PM, Peter Geoghegan <pg@bowt.ie> wrote:
>
> Cool. I pushed just the amcheck changes a moment ago. I attach the
> remaining changes from your v3, with a new draft commit message (no
> real changes). I didn't push the rest (what remains in the attached
> revision) just yet because I'm not quite sure about the approach used
> to exclude temp tables.

Thanks for that.

> Do we really need the redundancy between prepare_btree_command(),
> prepare_heap_command(), and compile_relation_list_one_db()? All three
> exclude temp relations, plus you have extra stuff in
> prepare_btree_command(). There is some theoretical value in delaying
> the index specific stuff until the query actually runs, at least in
> theory. But it also seems unlikely to make any appreciable difference
> to the overall level of coverage in practice.

I agree that it is unlikely to make much difference in practice.  Another session running reindex concurrently is, I
think,the most likely to conflict, but it is just barely imaginable that a relation will be dropped, and its OID reused
forsomething unrelated, by the time the check command gets run.  The new object might be temporary where the old object
wasnot.  On a properly functioning database, that may be too remote a possibility to be worth worrying about, but on a
corruptdatabase, most bets are off, and I can't really tell you if that's a likely scenario, because it is hard to
thinkabout all the different ways corruption might cause a database to behave.  On the other hand, the join against
pg_classmight fail due to unspecified corruption, so my attempt to play it safe may backfire. 

I don't feel strongly about this.  If you'd like me to remove those checks, I can do so.  These are just my thoughts on
thesubject. 

> Would it be simpler to do it all together, in
> compile_relation_list_one_db()? Were you concerned about things
> changing when parallel workers are run? Or something else?

Yeah, I was contemplating things changing by the time the parallel workers run the command.  I don't know how important
thatis. 

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company