Fix CommandCounterIncrement in partition-related DDL

It makes sense to do the CCIs in the places that do catalog updates,
rather than before the places that error out because the former ones
fail to do it.  In particular, it looks like StorePartitionBound() and
IndexSetParentIndex() ought to make their own CCIs.

Per review comments from Peter Eisentraut for row-level triggers on
partitioned tables.

Discussion: https://postgr.es/m/20171229225319.ajltgss2ojkfd3kp@alvherre.pgsql
This commit is contained in:
Alvaro Herrera 2018-03-20 11:19:41 -03:00
parent 467963c3e9
commit 4dba331cb3
3 changed files with 6 additions and 9 deletions

View File

@ -3298,6 +3298,9 @@ StorePartitionBound(Relation rel, Relation parent, PartitionBoundSpec *bound)
heap_freetuple(newtuple);
heap_close(classRel, RowExclusiveLock);
/* Make update visible */
CommandCounterIncrement();
/*
* The partition constraint for the default partition depends on the
* partition bounds of every other partition, so we must invalidate the

View File

@ -2512,5 +2512,8 @@ IndexSetParentIndex(Relation partitionIdx, Oid parentOid)
recordDependencyOn(&partIdx, &partitionTbl, DEPENDENCY_AUTO);
}
/* make our updates visible */
CommandCounterIncrement();
}
}

View File

@ -864,13 +864,6 @@ DefineRelation(CreateStmt *stmt, char relkind, Oid ownerId,
update_default_partition_oid(RelationGetRelid(parent), relationId);
heap_close(parent, NoLock);
/*
* The code that follows may also update the pg_class tuple to update
* relnumchecks, so bump up the command counter to avoid the "already
* updated by self" error.
*/
CommandCounterIncrement();
}
/*
@ -14585,8 +14578,6 @@ ATExecAttachPartitionIdx(List **wqueue, Relation parentIdx, RangeVar *name)
pfree(attmap);
CommandCounterIncrement();
validatePartitionedIndex(parentIdx, parentTbl);
}