Re: Corrupted btree index on HEAD because of covering indexes

Поиск
Список
Период
Сортировка
От Teodor Sigaev
Тема Re: Corrupted btree index on HEAD because of covering indexes
Дата
Msg-id 97545a73-3a3b-713d-31e2-8e652faa9152@sigaev.ru
обсуждение исходный текст
Ответ на Re: Corrupted btree index on HEAD because of covering indexes  (Peter Geoghegan <pg@bowt.ie>)
Ответы Re: Corrupted btree index on HEAD because of covering indexes  (Peter Geoghegan <pg@bowt.ie>)
Re: Corrupted btree index on HEAD because of covering indexes  (Peter Geoghegan <pg@bowt.ie>)
Список pgsql-hackers
> I'll take a look tomorrow.

Interesting, contrib/amcheck doesn't find any error in index. Seems, it's 
subject for further improvement.

Nevertheless, seems, I found. In _bt_mark_page_halfdead() we use truncated high 
key IndexTuple as a storage of blocknumber of top parent to remove. And sets 
BTreeTupleSetNAtts(&trunctuple, 0) - it's stored in ip_posid.

But some later, in _bt_unlink_halfdead_page() we check ItemPointer high key with 
ItemPointerIsValid macro - and it returns false, because offset is actually 
InvalidOffsetNumber - i.e. 0 which was set by BTreeTupleSetNAtts. And some wrong 
decisions are follows, I didn't look at that.

Trivial and naive fix is attached, but for me it looks a bit annoing that we 
store pointer (leafhikey) somewhere inside unlocked page.



-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
                                                    WWW: http://www.sigaev.ru/

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: pruning disabled for array, enum, record, range type partitionkeys
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: ON CONFLICT DO UPDATE for partitioned tables