Re: BUG #17212: pg_amcheck fails on checking temporary relations
От | Mark Dilger |
---|---|
Тема | Re: BUG #17212: pg_amcheck fails on checking temporary relations |
Дата | |
Msg-id | 07159C9A-40DA-47BF-B2F4-203F5AC00890@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 6, 2021, at 4:12 PM, Peter Geoghegan <pg@bowt.ie> wrote: > >> >> Ok, excellent, that was probably the only thing that had me really hung up. I thought you were still asking for pg_amcheckto filter out the --parent-check option when in recovery, but if you're not asking for that, then I might haveenough to go on now. > > Sorry about that. I realized my mistake (not specifically addressing > pg_is_in_recovery()) after I hit "send", and should have corrected the > record sooner. > >> I was using "downgrading" to mean downgrading from bt_index_parent_check() to bt_index_check() when pg_is_in_recovery()is true, but you've clarified that you're not requesting that downgrade, so I think we've now gotten pastthe last sticking point about that whole issue. > > Right. I never meant anything like making a would-be > bt_index_parent_check() call into a bt_index_check() call, just > because of the state of the system (e.g., it's in recovery). That > seems awful, in fact. Please find attached the latest version of the patch which includes the changes we discussed. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Вложения
В списке pgsql-hackers по дате отправления: