Wups, managed to break ANALYZE with one aspect of that heap_fetch change.

diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
index e763823a1663cd5202c296562166cb71be96ba4b..a6f7e59fae7243c4ec475fa21b62befa12b3f840 100644 (file)
--- a/src/backend/access/heap/heapam.c
+++ b/src/backend/access/heap/heapam.c
@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *       $Header: /cvsroot/pgsql/src/backend/access/heap/heapam.c,v 1.136 2002/05/24 18:57:55 tgl Exp $
+ *       $Header: /cvsroot/pgsql/src/backend/access/heap/heapam.c,v 1.137 2002/05/24 19:52:43 tgl Exp $
  *
  *
  * INTERFACE ROUTINES
@@ -873,15 +873,24 @@ heap_getnext(HeapScanDesc scan, ScanDirection direction)
  * the tuple, fill in the remaining fields of *tuple, and check the tuple
  * against the specified snapshot.
  *
- * If successful (tuple passes snapshot time qual), then *userbuf is set to
- * the buffer holding the tuple and TRUE is returned.  The caller must
- * unpin the buffer when done with the tuple.
+ * If successful (tuple found and passes snapshot time qual), then *userbuf
+ * is set to the buffer holding the tuple and TRUE is returned.  The caller
+ * must unpin the buffer when done with the tuple.
  *
- * If the tuple fails the time qual check, then FALSE will be returned.
- * When the caller specifies keep_buf = true, we retain the pin on the
- * buffer and return it in *userbuf (so the caller can still access the
- * tuple); when keep_buf = false, the pin is released and *userbuf is set
+ * If the tuple is not found, then tuple->t_data is set to NULL, *userbuf
+ * is set to InvalidBuffer, and FALSE is returned.
+ *
+ * If the tuple is found but fails the time qual check, then FALSE will be
+ * returned. When the caller specifies keep_buf = true, we retain the pin
+ * on the buffer and return it in *userbuf (so the caller can still access
+ * the tuple); when keep_buf = false, the pin is released and *userbuf is set
  * to InvalidBuffer.
+ *
+ * It is somewhat inconsistent that we elog() on invalid block number but
+ * return false on invalid item number.  This is historical.  The only
+ * justification I can see is that the caller can relatively easily check the
+ * block number for validity, but cannot check the item number without reading
+ * the page himself.
  */
 bool
 heap_fetch(Relation relation,
@@ -928,17 +937,18 @@ heap_fetch(Relation relation,
        lp = PageGetItemId(dp, offnum);
 
        /*
-        * more sanity checks
+        * must check for deleted tuple (see for example analyze.c, which is
+        * careful to pass an offnum in range, but doesn't know if the offnum
+        * actually corresponds to an undeleted tuple).
         */
        if (!ItemIdIsUsed(lp))
        {
                LockBuffer(buffer, BUFFER_LOCK_UNLOCK);
                ReleaseBuffer(buffer);
-
-               elog(ERROR, "heap_fetch: invalid tuple id (%s, %lu, %u)",
-                        RelationGetRelationName(relation),
-                        (unsigned long) ItemPointerGetBlockNumber(tid),
-                        offnum);
+               *userbuf = InvalidBuffer;
+               tuple->t_datamcxt = NULL;
+               tuple->t_data = NULL;
+               return false;
        }
 
        /*

diff --git a/src/backend/access/index/indexam.c b/src/backend/access/index/indexam.c
index 8c0fbaa6a11da27628ff755336710b7e35602b70..475a613204aca50d6a959cbc3bc8aa0c965b81a3 100644 (file)
--- a/src/backend/access/index/indexam.c
+++ b/src/backend/access/index/indexam.c
@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *       $Header: /cvsroot/pgsql/src/backend/access/index/indexam.c,v 1.59 2002/05/24 18:57:55 tgl Exp $
+ *       $Header: /cvsroot/pgsql/src/backend/access/index/indexam.c,v 1.60 2002/05/24 19:52:43 tgl Exp $
  *
  * INTERFACE ROUTINES
  *             index_open              - open an index relation by relation OID
@@ -444,6 +444,10 @@ index_getnext(IndexScanDesc scan, ScanDirection direction)
                                           &scan->xs_pgstat_info))
                        break;
 
+               /* Skip if no tuple at this location */
+               if (heapTuple->t_data == NULL)
+                       continue;                       /* should we raise an error instead? */
+
                /*
                 * If we can't see it, maybe no one else can either.  Check to see
                 * if the tuple is dead to all transactions.  If so, signal the

diff --git a/src/backend/access/nbtree/nbtinsert.c b/src/backend/access/nbtree/nbtinsert.c
index fe3e98b982c322c4fdc059a543b8dc0a9bef5832..27d0fc85c46bf4eee1b16707c8fcbeb1c7371707 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.91 2002/05/24 18:57:55 tgl Exp $
+ *       $Header: /cvsroot/pgsql/src/backend/access/nbtree/nbtinsert.c,v 1.92 2002/05/24 19:52:43 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -248,7 +248,7 @@ _bt_check_unique(Relation rel, BTItem btitem, Relation heapRel,
                                        elog(ERROR, "Cannot insert a duplicate key into unique index %s",
                                                 RelationGetRelationName(rel));
                                }
-                               else
+                               else if (htup.t_data != NULL)
                                {
                                        /*
                                         * Hmm, if we can't see the tuple, maybe it can be