BTP_DELETED leaf still in tree

From: Daniel Wood <hexexpert(at)comcast(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Subject: BTP_DELETED leaf still in tree
Date: 2019-10-10 19:48:18
Message-ID: 1455619995.967028.1570736898537@connect.xfinity.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-10-10 19:55:32 Re: generating catcache control data
Previous Message Tom Lane 2019-10-10 19:14:34 Re: generating catcache control data