Re: BUG #16833: postgresql 13.1 process crash every hour

Поиск
Список
Период
Сортировка
Искать
От
Peter Geoghegan
Тема
Re: BUG #16833: postgresql 13.1 process crash every hour
Дата
в 19:25:07
Msg-id
CAH2-WznTmpKTQVE1iJdNZs=G0DHEUbNL8Wc9O0c5T3F7oB0DEA@mail.gmail.com
Ответ на
Список
Дерево обсуждения
BUG #16833: postgresql 13.1 process crash every hour PG Bug reporting form <noreply@postgresql.org>
Re: BUG #16833: postgresql 13.1 process crash every hour Tom Lane <tgl@sss.pgh.pa.us>
Re: BUG #16833: postgresql 13.1 process crash every hour Alex F <phoedos16@gmail.com>
Re: BUG #16833: postgresql 13.1 process crash every hour Andres Freund <andres@anarazel.de>
On Fri, May 14, 2021 at 12:12 PM Alex F  wrote:
> Dear Peter,
> Honestly don't know if you expect a response with amcheck results but anyway will paste it here:

It is helpful -- thanks!

It should be possible to avoid this problem by reindexing. Of course
it's important to eliminate whatever the source of the corruption is,
which might be much harder.

Could you execute exactly the same query, only this time use
"bt_index_check(index => c.oid, heapallindexed => true)" in place of
the bt_index_parent_check() call from the original query? Maybe there
is something more to be learned by just focussing on the leaf pages,
and not failing earlier on, in the parent pages. The less thorough
bt_index_check() function can sometimes show something interesting by
failing later than bt_index_parent_check() would fail with the same
index.

I note that the amcheck error message that you showed happens between
level 2 and level 1, neither of which are leaf level (that's level 0)
-- only leaf pages can have posting list tuples. To me this suggests
that the chances of corruption being a bug in deduplication
specifically are very remote (it's more likely to be a bug in some
other place, even). I'm always curious about real world corruption, so
I'd still appreciate seeing the bt_index_check() variant query's
output just to satisfy myself that that's what it is.

-- 
Peter Geoghegan


В списке pgsql-bugs по дате отправления
От: Alex F
Дата:
От: Shay Rojansky
Дата:
FAQ