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

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>, Alexander Lakhin <exclusion(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: BUG #17212: pg_amcheck fails on checking temporary relations
Date: 2021-10-12 00:37:51
Message-ID: CAH2-Wzm0k++pWW4T8SyKWHn1uQd17Ay5=ooZZPZoZE_fS7i49g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On Mon, Oct 11, 2021 at 2:41 PM Mark Dilger
<mark(dot)dilger(at)enterprisedb(dot)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 Content-Type Size
v4-0001-pg_amcheck-avoid-unhelpful-verification-attempts.patch application/octet-stream 18.3 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Zhihong Zhang 2021-10-12 00:48:54 Re: Epoch from age is incorrect
Previous Message Tom Lane 2021-10-11 22:55:25 Re: v12.4 pg_dump .sql fails to load data via psql

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2021-10-12 00:53:07 Re: Fix pg_log_backend_memory_contexts() 's delay
Previous Message Masahiko Sawada 2021-10-12 00:25:46 Re: Parallel vacuum workers prevent the oldest xmin from advancing