BTP_DELETED leaf still in tree - Mailing list pgsql-hackers

From Daniel Wood
Subject BTP_DELETED leaf still in tree
Date
Msg-id 1455619995.967028.1570736898537@connect.xfinity.com
Whole thread Raw
Responses Re: BTP_DELETED leaf still in tree
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: generating catcache control data
Next
From: Tom Lane
Date:
Subject: Re: generating catcache control data