Re: BUG #17212: pg_amcheck fails on checking temporary relations
От | Mark Dilger |
---|---|
Тема | Re: BUG #17212: pg_amcheck fails on checking temporary relations |
Дата | |
Msg-id | F966FBB2-7706-483F-92AE-A99F55BD3926@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: BUG #17212: pg_amcheck fails on checking temporary relations (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: BUG #17212: pg_amcheck fails on checking temporary relations
|
Список | pgsql-hackers |
> On Oct 11, 2021, at 2:33 PM, Peter Geoghegan <pg@bowt.ie> wrote: > > 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. Ok, that makes more sense. Would you care to rephrase them? I don't think we need another round of patches posted. > 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? I'd appreciate if you could fix up the <warning> in the docs and do the commit. Thanks! — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: