On Fri, May 8, 2015 at 11:35 AM, Andres Freund <and...@anarazel.de> wrote:
> I think Peter (on IM) just found a more likely explanation than mine.
>
> index_close(idxRel, NoLock);
> heap_close(relation, NoLock);
> candidates = lappend_oid(candidates,
> idxForm->indexrelid);
> ...
>
> Yes. idxForm points into idxRel->rd_index.
>
> He's working on a fix for both this and removal of the still unnecessary
> indcheckxmin check.
This was my (last minute) blunder, in case it matters.
Attached patch fixes the bug, and removes the unnecessary indcheckxmin check.
--
Peter Geoghegan
diff --git a/src/backend/optimizer/util/plancat.c b/src/backend/optimizer/util/plancat.c
index 8bcc506..1d555ed 100644
--- a/src/backend/optimizer/util/plancat.c
+++ b/src/backend/optimizer/util/plancat.c
@@ -547,15 +547,11 @@ infer_arbiter_indexes(PlannerInfo *root)
goto next;
/*
- * If the index is valid, but cannot yet be used, ignore it. See
- * src/backend/access/heap/README.HOT for discussion.
- */
- if (idxForm->indcheckxmin &&
- !TransactionIdPrecedes(HeapTupleHeaderGetXmin(idxRel->rd_indextuple->t_data),
- TransactionXmin))
- goto next;
-
- /*
+ * Note that we do not perform a get_relation_info()-style check
+ * against indcheckxmin here to eliminate candidates, because
+ * uniqueness checking only cares about the most recently committed
+ * tuple versions.
+ *
* Look for match on "ON constraint_name" variant, which may not be
* unique constraint. This can only be a constraint name.
*/
@@ -566,10 +562,10 @@ infer_arbiter_indexes(PlannerInfo *root)
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
errmsg("ON CONFLICT DO UPDATE not supported with exclusion constraints")));
+ candidates = lappend_oid(candidates, idxForm->indexrelid);
list_free(indexList);
index_close(idxRel, NoLock);
heap_close(relation, NoLock);
- candidates = lappend_oid(candidates, idxForm->indexrelid);
return candidates;
}
else if (indexOidFromConstraint != InvalidOid)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
