Re: BUG #16833: postgresql 13.1 process crash every hour
От | Peter Geoghegan |
---|---|
Тема | Re: BUG #16833: postgresql 13.1 process crash every hour |
Дата | |
Msg-id | CAH2-WznTmpKTQVE1iJdNZs=G0DHEUbNL8Wc9O0c5T3F7oB0DEA@mail.gmail.com обсуждение исходный текст |
Ответ на | 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
|
Список | pgsql-bugs |
On Fri, May 14, 2021 at 12:12 PM Alex F <phoedos16@gmail.com> 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 по дате отправления: