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 27c833408d67dc423480e56d1caf775ed9d358c1..d2644b25ddeae5a01678d6f913e1bdf4451f0426 100644 (file)
--- a/src/backend/access/nbtree/nbtinsert.c
+++ b/src/backend/access/nbtree/nbtinsert.c
@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *       $Header: /cvsroot/pgsql/src/backend/access/nbtree/nbtinsert.c,v 1.106 2003/09/25 06:57:57 petere Exp $
+ *       $Header: /cvsroot/pgsql/src/backend/access/nbtree/nbtinsert.c,v 1.106.2.1 2004/08/17 23:16:07 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -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