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 ed08d65d99d8dbf66bd76f169cfa83862fd893d2..7cc019d8743faf8578cacaa787ecdae51f9e48c8 100644 (file)
--- a/src/backend/access/nbtree/nbtinsert.c
+++ b/src/backend/access/nbtree/nbtinsert.c
@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *       $PostgreSQL: pgsql/src/backend/access/nbtree/nbtinsert.c,v 1.113 2004/07/21 22:31:19 tgl Exp $
+ *       $PostgreSQL: pgsql/src/backend/access/nbtree/nbtinsert.c,v 1.114 2004/08/17 23:15:33 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -1311,6 +1311,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