> 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
