BTP_DELETED leaf still in tree

Поиск
Список
Период
Сортировка
От Daniel Wood
Тема BTP_DELETED leaf still in tree
Дата
Msg-id 1455619995.967028.1570736898537@connect.xfinity.com
обсуждение исходный текст
Ответы Re: BTP_DELETED leaf still in tree  (Peter Geoghegan <pg@bowt.ie>)
Список pgsql-hackers

Update query stuck in a loop.  Looping in _bt_moveright().

ExecInsertIndexTuples->btinsert->_bt_doinsert->_bt_search->_bt_moveright

Mid Tree Node downlink path taken by _bt_search points to a BTP_DELETED Leaf.

btpo_next is also DELETED but not in the tree.

btpo_next->btpo_next is NOT deleted but in the mid tree as a lesser key value.

Thus creating an endless loop in moveright.


The deleted page is in the tree.  The left leaf page still points to it.  The right leaf page points back to the deleted page.

The deleted page itself has arbitrary prev and next pointer.  But the next pointer does lead to a loop.


Is there any way, crash recovery or otherwise, that could result in a BTP_DELETED leaf which is still in the tree both in terms of the mid tree pointing down to it but also linked to by the 2 leaf siblings.  It is as if the mid tree and two siblings were updated but never made it to disk but the DELETED page itself got written.


Even after a restart the hang reoccurred.  Rebuild fixed the problem.  Unfortunately I'm not sure if I have enough log history left to examine.  But I do have the index file before the rebuild and it clearly has the loop on disk.



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: generating catcache control data
Следующее
От: Tom Lane
Дата:
Сообщение: Re: generating catcache control data