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.
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 |