Re: BUG #17212: pg_amcheck fails on checking temporary relations - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: BUG #17212: pg_amcheck fails on checking temporary relations
Date
Msg-id CAH2-Wzm0k++pWW4T8SyKWHn1uQd17Ay5=ooZZPZoZE_fS7i49g@mail.gmail.com
Whole thread Raw
In response to Re: BUG #17212: pg_amcheck fails on checking temporary relations  (Mark Dilger <mark.dilger@enterprisedb.com>)
Responses Re: BUG #17212: pg_amcheck fails on checking temporary relations  (Mark Dilger <mark.dilger@enterprisedb.com>)
List pgsql-hackers
On Mon, Oct 11, 2021 at 2:41 PM Mark Dilger
<mark.dilger@enterprisedb.com> wrote:
> > Overall, your approach looks good to me. Will Robert take care of
> > committing this, or should I?
>
> I'd appreciate if you could fix up the <warning> in the docs and do the commit.

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.

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.

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?

Many thanks
--
Peter Geoghegan

Attachment

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Parallel vacuum workers prevent the oldest xmin from advancing
Next
From: Fujii Masao
Date:
Subject: Re: Fix pg_log_backend_memory_contexts() 's delay