Repair oversight in recent changes to index-creation: tuple time qual

check *can* return HEAPTUPLE_INSERT_IN_PROGRESS or HEAPTUPLE_DELETE_IN_PROGRESS,
even though we have ShareLock on the relation.  To wit, this can happen
if the tuple was inserted/deleted by our own transaction.  Per report from
Justin Clift 9/23.

diff --git a/src/backend/catalog/index.c b/src/backend/catalog/index.c
index 9debf84cab4385692936b221f7e68342eba3856a..c850c55a0f50f202c5e0a7ac69b2f8d2fcb318f3 100644 (file)
--- a/src/backend/catalog/index.c
+++ b/src/backend/catalog/index.c
@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *       $Header: /cvsroot/pgsql/src/backend/catalog/index.c,v 1.163 2001/08/26 16:55:59 tgl Exp $
+ *       $Header: /cvsroot/pgsql/src/backend/catalog/index.c,v 1.164 2001/09/26 21:09:27 tgl Exp $
  *
  *
  * INTERFACE ROUTINES
@@ -1789,19 +1789,27 @@ IndexBuildHeapScan(Relation heapRelation,
                                        break;
                                case HEAPTUPLE_INSERT_IN_PROGRESS:
                                        /*
-                                        * This should not happen, if caller holds ShareLock on
-                                        * the parent relation.
+                                        * Since caller should hold ShareLock or better, we should
+                                        * not see any tuples inserted by open transactions ---
+                                        * unless it's our own transaction.  (Consider INSERT
+                                        * followed by CREATE INDEX within a transaction.)
                                         */
-                                       elog(ERROR, "IndexBuildHeapScan: concurrent insert in progress");
-                                       indexIt = tupleIsAlive = false; /* keep compiler quiet */
+                                       if (! TransactionIdIsCurrentTransactionId(heapTuple->t_data->t_xmin))
+                                               elog(ERROR, "IndexBuildHeapScan: concurrent insert in progress");
+                                       indexIt = true;
+                                       tupleIsAlive = true;
                                        break;
                                case HEAPTUPLE_DELETE_IN_PROGRESS:
                                        /*
-                                        * This should not happen, if caller holds ShareLock on
-                                        * the parent relation.
+                                        * Since caller should hold ShareLock or better, we should
+                                        * not see any tuples deleted by open transactions ---
+                                        * unless it's our own transaction.  (Consider DELETE
+                                        * followed by CREATE INDEX within a transaction.)
                                         */
-                                       elog(ERROR, "IndexBuildHeapScan: concurrent delete in progress");
-                                       indexIt = tupleIsAlive = false; /* keep compiler quiet */
+                                       if (! TransactionIdIsCurrentTransactionId(heapTuple->t_data->t_xmax))
+                                               elog(ERROR, "IndexBuildHeapScan: concurrent delete in progress");
+                                       indexIt = true;
+                                       tupleIsAlive = false;
                                        break;
                                default:
                                        elog(ERROR, "Unexpected HeapTupleSatisfiesVacuum result");