Fix bug introduced into _bt_getstackbuf() on 2003-Feb-21: the initial

value of 'start' could be past the end of the page, if the page was
split by some concurrent inserting process since we visited it.  In
this situation the code could look at bogus entries and possibly find
a match (since after all those entries still contain what they had
before the split).  This would lead to 'specified item offset is too large'
followed by 'PANIC: failed to add item to the page', as reported by Joe
Conway for scenarios involving heavy concurrent insertion activity.

diff --git a/src/backend/access/nbtree/nbtinsert.c b/src/backend/access/nbtree/nbtinsert.c
index 6a6a043d708b26daf634d4d94109307a7126f0ca..f85200328eb552b04fc0807e51a81a96ecf360d3 100644 (file)
--- a/src/backend/access/nbtree/nbtinsert.c
+++ b/src/backend/access/nbtree/nbtinsert.c
@@ -1315,6 +1315,13 @@ _bt_getstackbuf(Relation rel, BTStack stack, int access)
                        if (start < minoff)
                                start = minoff;
 
+                       /*
+                        * Need this check too, to guard against possibility that page
+                        * split since we visited it originally.
+                        */
+                       if (start > maxoff)
+                               start = OffsetNumberNext(maxoff);
+
                        /*
                         * These loops will check every item on the page --- but in an
                         * order that's attuned to the probability of where it