aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/execMain.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2020-09-16 14:28:11 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2020-09-16 14:28:18 -0400
commit2000b6c10aa6777929f1a8b613f30426bb90f849 (patch)
treecddc528b8c188e3f45e77bdd3d18676f2685a364 /src/backend/executor/execMain.c
parentaac80bfcddf7df3fbd1eb73e8a386115d922c714 (diff)
downloadpostgresql-2000b6c10aa6777929f1a8b613f30426bb90f849.tar.gz
postgresql-2000b6c10aa6777929f1a8b613f30426bb90f849.zip
Don't fetch partition check expression during InitResultRelInfo.
Since there is only one place that actually needs the partition check expression, namely ExecPartitionCheck, it's better to fetch it from the relcache there. In this way we will never fetch it at all if the query never has use for it, and we still fetch it just once when we do need it. The reason for taking an interest in this is that if the relcache doesn't already have the check expression cached, fetching it requires obtaining AccessShareLock on the partition root. That means that operations that look like they should only touch the partition itself will also take a lock on the root. In particular we observed that TRUNCATE on a partition may take a lock on the partition's root, contributing to a deadlock situation in parallel pg_restore. As written, this patch does have a small cost, which is that we are microscopically reducing efficiency for the case where a partition has an empty check expression. ExecPartitionCheck will be called, and will go through the motions of setting up and checking an empty qual, where before it would not have been called at all. We could avoid that by adding a separate boolean flag to track whether there is a partition expression to test. However, this case only arises for a default partition with no siblings, which surely is not an interesting case in practice. Hence adding complexity for it does not seem like a good trade-off. Amit Langote, per a suggestion by me Discussion: https://postgr.es/m/VI1PR03MB31670CA1BD9625C3A8C5DD05EB230@VI1PR03MB3167.eurprd03.prod.outlook.com
Diffstat (limited to 'src/backend/executor/execMain.c')
-rw-r--r--src/backend/executor/execMain.c41
1 files changed, 15 insertions, 26 deletions
diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c
index 4fdffad6f35..2e27e26ba44 100644
--- a/src/backend/executor/execMain.c
+++ b/src/backend/executor/execMain.c
@@ -1280,8 +1280,6 @@ InitResultRelInfo(ResultRelInfo *resultRelInfo,
Relation partition_root,
int instrument_options)
{
- List *partition_check = NIL;
-
MemSet(resultRelInfo, 0, sizeof(ResultRelInfo));
resultRelInfo->type = T_ResultRelInfo;
resultRelInfo->ri_RangeTableIndex = resultRelationIndex;
@@ -1325,23 +1323,6 @@ InitResultRelInfo(ResultRelInfo *resultRelInfo,
resultRelInfo->ri_ReturningSlot = NULL;
resultRelInfo->ri_TrigOldSlot = NULL;
resultRelInfo->ri_TrigNewSlot = NULL;
-
- /*
- * Partition constraint, which also includes the partition constraint of
- * all the ancestors that are partitions. Note that it will be checked
- * even in the case of tuple-routing where this table is the target leaf
- * partition, if there any BR triggers defined on the table. Although
- * tuple-routing implicitly preserves the partition constraint of the
- * target partition for a given row, the BR triggers may change the row
- * such that the constraint is no longer satisfied, which we must fail for
- * by checking it explicitly.
- *
- * If this is a partitioned table, the partition constraint (if any) of a
- * given row will be checked just before performing tuple-routing.
- */
- partition_check = RelationGetPartitionQual(resultRelationDesc);
-
- resultRelInfo->ri_PartitionCheck = partition_check;
resultRelInfo->ri_PartitionRoot = partition_root;
resultRelInfo->ri_PartitionInfo = NULL; /* may be set later */
resultRelInfo->ri_CopyMultiInsertBuffer = NULL;
@@ -1776,7 +1757,7 @@ ExecRelCheck(ResultRelInfo *resultRelInfo,
* ExecPartitionCheck --- check that tuple meets the partition constraint.
*
* Returns true if it meets the partition constraint. If the constraint
- * fails and we're asked to emit to error, do so and don't return; otherwise
+ * fails and we're asked to emit an error, do so and don't return; otherwise
* return false.
*/
bool
@@ -1788,14 +1769,22 @@ ExecPartitionCheck(ResultRelInfo *resultRelInfo, TupleTableSlot *slot,
/*
* If first time through, build expression state tree for the partition
- * check expression. Keep it in the per-query memory context so they'll
- * survive throughout the query.
+ * check expression. (In the corner case where the partition check
+ * expression is empty, ie there's a default partition and nothing else,
+ * we'll be fooled into executing this code each time through. But it's
+ * pretty darn cheap in that case, so we don't worry about it.)
*/
if (resultRelInfo->ri_PartitionCheckExpr == NULL)
{
- List *qual = resultRelInfo->ri_PartitionCheck;
+ /*
+ * Ensure that the qual tree and prepared expression are in the
+ * query-lifespan context.
+ */
+ MemoryContext oldcxt = MemoryContextSwitchTo(estate->es_query_cxt);
+ List *qual = RelationGetPartitionQual(resultRelInfo->ri_RelationDesc);
resultRelInfo->ri_PartitionCheckExpr = ExecPrepareCheck(qual, estate);
+ MemoryContextSwitchTo(oldcxt);
}
/*
@@ -1904,9 +1893,9 @@ ExecConstraints(ResultRelInfo *resultRelInfo,
Bitmapset *insertedCols;
Bitmapset *updatedCols;
- Assert(constr || resultRelInfo->ri_PartitionCheck);
+ Assert(constr); /* we should not be called otherwise */
- if (constr && constr->has_not_null)
+ if (constr->has_not_null)
{
int natts = tupdesc->natts;
int attrChk;
@@ -1967,7 +1956,7 @@ ExecConstraints(ResultRelInfo *resultRelInfo,
}
}
- if (constr && constr->num_check > 0)
+ if (constr->num_check > 0)
{
const char *failed;