Re: BUG #17212: pg_amcheck fails on checking temporary relations
От | Mark Dilger |
---|---|
Тема | Re: BUG #17212: pg_amcheck fails on checking temporary relations |
Дата | |
Msg-id | CACF59A6-865B-4D42-B8E4-39CD64F8CEA4@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 4, 2021, at 6:19 PM, Peter Geoghegan <pg@bowt.ie> wrote: > > I don't see what the point of this example is. It doesn't matter. 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. 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 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. It doesn't get as far as btree_index_mainfork_expected(). So I am changing pg_amcheck to filter out indexes when pg_is_in_recovery()is true and relpersistence='u'. Does that sound right to you? — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: