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-WznCQU7D0aNto5r8V6Qy7JOn+Saaev6jzVrY6GBZLmLFSA@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
List pgsql-hackers
On Mon, Oct 11, 2021 at 1:20 PM Mark Dilger
<mark.dilger@enterprisedb.com> wrote:
> Ok, I went with this suggestion, and also your earlier suggestion to have a <warning> in the pg_amcheck docs about
using--parent-check and/or --rootdescend against servers in recovery.
 

My concern with --parent-check (and with --rootdescend) had little to
do with Hot Standby. I suggested using a warning because these options
alone can pretty much cause bedlam on a production database. At least
if they're used carelessly. Again, bt_index_parent_check()'s relation
level locks will block all DML, as well as VACUUM. That isn't the case
with any of the other pg_amcheck options, including those that call
bt_index_check(), and including the heapam verification functionality.

It's also true that --parent-check won't work in Hot Standby mode, of
course. So it couldn't hurt to mention that in passing, at the same
point. But that's a secondary point, at best. We don't need to use a
warning box because of that.

Overall, your approach looks good to me. Will Robert take care of
committing this, or should I?

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: pg14 psql broke \d datname.nspname.relname
Next
From: Mark Dilger
Date:
Subject: Re: BUG #17212: pg_amcheck fails on checking temporary relations