Correct an old logic error in btree page splitting: when considering a split

exactly at the point where we need to insert a new item, the calculation used
the wrong size for the "high key" of the new left page.  This could lead to
choosing an unworkable split, resulting in "PANIC: failed to add item to the
left sibling" (or "right sibling") failure.  Although this bug has been there
a long time, it's very difficult to trigger a failure before 8.2, since there
was generally a lot of free space on both sides of a chosen split.  In 8.2,
where the user-selected fill factor determines how much free space the code
tries to leave, an unworkable split is much more likely.  Report by Joe
Conway, diagnosis and fix by Heikki Linnakangas.

diff --git a/src/backend/access/nbtree/nbtinsert.c b/src/backend/access/nbtree/nbtinsert.c
index 9389413c76cafebc95888f4e2630bc8a32737064..60cb8410fb059548616fd9508dc7e8a828694f55 100644 (file)
--- a/src/backend/access/nbtree/nbtinsert.c
+++ b/src/backend/access/nbtree/nbtinsert.c
@@ -1063,7 +1063,12 @@ _bt_findsplitloc(Relation rel,
                        /* need to try it both ways! */
                        _bt_checksplitloc(&state, offnum, leftfree, rightfree,
                                                          true, itemsz);
-                       /* here we are contemplating newitem as first on right */
+                       /*
+                        * Here we are contemplating newitem as first on right.  In this
+                        * case it, not the current item, will become the high key of the
+                        * left page, and so we have to correct the allowance made above.
+                        */
+                       leftfree += (int) itemsz - (int) newitemsz;
                        _bt_checksplitloc(&state, offnum, leftfree, rightfree,
                                                          false, newitemsz);
                }