Re: BUG #17212: pg_amcheck fails on checking temporary relations
От | Peter Geoghegan |
---|---|
Тема | Re: BUG #17212: pg_amcheck fails on checking temporary relations |
Дата | |
Msg-id | CAH2-WzkPc3O91uYSAnrDMyEZGpcJh5ccqH-QgnfL1Kts13Ga7g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #17212: pg_amcheck fails on checking temporary relations (Mark Dilger <mark.dilger@enterprisedb.com>) |
Список | pgsql-hackers |
On Mon, Oct 4, 2021 at 8:19 PM Mark Dilger <mark.dilger@enterprisedb.com> wrote: > I am changing pg_amcheck to filter out indexes as you say. Since the btree check should no longer error in these cases,the issue of pg_amcheck exit(2) sorts itself out without further code changes. Cool. > I am changing verify_heapam to skip unlogged tables during recovery. In testing, checking such a table results in a simplenotice: > > NOTICE: cannot verify unlogged relation "u_tbl" during recovery, skipping That makes sense to me. > While testing, I also created an index on the unlogged table and checked that index using bt_index_parent_check, and wassurprised that checking it using bt_index_parent_check raises an error: > > ERROR: cannot acquire lock mode ShareLock on database objects while recovery is in progress > HINT: Only RowExclusiveLock or less can be acquired on database objects during recovery. Calling bt_index_parent_check() in hot standby mode is kind of asking for it to error-out. It requires a ShareLock on the relation, which is inherently not possible during recovery. So I don't feel too badly about letting it just happen. > So I am changing pg_amcheck to filter out indexes when pg_is_in_recovery() is true and relpersistence='u'. Does that soundright to you? Yes, that all sounds right to me. Thanks -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: