2009-10-10 03:43:50 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* nodeModifyTable.c
|
|
|
|
* routines to handle ModifyTable nodes.
|
|
|
|
*
|
2017-01-03 19:48:53 +01:00
|
|
|
* Portions Copyright (c) 1996-2017, PostgreSQL Global Development Group
|
2009-10-10 03:43:50 +02:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
*
|
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/backend/executor/nodeModifyTable.c
|
2009-10-10 03:43:50 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
/* INTERFACE ROUTINES
|
2010-02-26 03:01:40 +01:00
|
|
|
* ExecInitModifyTable - initialize the ModifyTable node
|
2009-10-10 03:43:50 +02:00
|
|
|
* ExecModifyTable - retrieve the next tuple from the node
|
|
|
|
* ExecEndModifyTable - shut down the ModifyTable node
|
|
|
|
* ExecReScanModifyTable - rescan the ModifyTable node
|
|
|
|
*
|
|
|
|
* NOTES
|
|
|
|
* Each ModifyTable node contains a list of one or more subplans,
|
|
|
|
* much like an Append node. There is one subplan per result relation.
|
|
|
|
* The key reason for this is that in an inherited UPDATE command, each
|
|
|
|
* result relation could have a different schema (more or different
|
|
|
|
* columns) requiring a different plan tree to produce it. In an
|
|
|
|
* inherited DELETE, all the subplans should produce the same output
|
|
|
|
* rowtype, but we might still find that different plans are appropriate
|
|
|
|
* for different child relations.
|
|
|
|
*
|
|
|
|
* If the query specifies RETURNING, then the ModifyTable returns a
|
|
|
|
* RETURNING tuple after completing each row insert, update, or delete.
|
2014-05-06 18:12:18 +02:00
|
|
|
* It must be called again to continue the operation. Without RETURNING,
|
2009-10-10 03:43:50 +02:00
|
|
|
* we just loop within the node until all the work is done, then
|
|
|
|
* return NULL. This avoids useless call/return overhead.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "postgres.h"
|
|
|
|
|
2012-08-30 22:15:44 +02:00
|
|
|
#include "access/htup_details.h"
|
2009-10-10 03:43:50 +02:00
|
|
|
#include "access/xact.h"
|
|
|
|
#include "commands/trigger.h"
|
|
|
|
#include "executor/executor.h"
|
|
|
|
#include "executor/nodeModifyTable.h"
|
2013-03-10 19:14:53 +01:00
|
|
|
#include "foreign/fdwapi.h"
|
2009-10-10 03:43:50 +02:00
|
|
|
#include "miscadmin.h"
|
|
|
|
#include "nodes/nodeFuncs.h"
|
2017-03-21 14:48:04 +01:00
|
|
|
#include "parser/parsetree.h"
|
2009-10-10 03:43:50 +02:00
|
|
|
#include "storage/bufmgr.h"
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
#include "storage/lmgr.h"
|
2009-10-10 03:43:50 +02:00
|
|
|
#include "utils/builtins.h"
|
|
|
|
#include "utils/memutils.h"
|
2011-02-23 18:18:09 +01:00
|
|
|
#include "utils/rel.h"
|
2009-10-10 03:43:50 +02:00
|
|
|
#include "utils/tqual.h"
|
|
|
|
|
|
|
|
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
static bool ExecOnConflictUpdate(ModifyTableState *mtstate,
|
|
|
|
ResultRelInfo *resultRelInfo,
|
|
|
|
ItemPointer conflictTid,
|
|
|
|
TupleTableSlot *planSlot,
|
|
|
|
TupleTableSlot *excludedSlot,
|
|
|
|
EState *estate,
|
|
|
|
bool canSetTag,
|
|
|
|
TupleTableSlot **returning);
|
|
|
|
|
2009-10-10 03:43:50 +02:00
|
|
|
/*
|
|
|
|
* Verify that the tuples to be produced by INSERT or UPDATE match the
|
|
|
|
* target relation's rowtype
|
|
|
|
*
|
|
|
|
* We do this to guard against stale plans. If plan invalidation is
|
|
|
|
* functioning properly then we should never get a failure here, but better
|
|
|
|
* safe than sorry. Note that this is called after we have obtained lock
|
|
|
|
* on the target rel, so the rowtype can't change underneath us.
|
|
|
|
*
|
|
|
|
* The plan output is represented by its targetlist, because that makes
|
|
|
|
* handling the dropped-column case easier.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
ExecCheckPlanOutput(Relation resultRel, List *targetList)
|
|
|
|
{
|
|
|
|
TupleDesc resultDesc = RelationGetDescr(resultRel);
|
|
|
|
int attno = 0;
|
|
|
|
ListCell *lc;
|
|
|
|
|
|
|
|
foreach(lc, targetList)
|
|
|
|
{
|
|
|
|
TargetEntry *tle = (TargetEntry *) lfirst(lc);
|
|
|
|
Form_pg_attribute attr;
|
|
|
|
|
|
|
|
if (tle->resjunk)
|
|
|
|
continue; /* ignore junk tlist items */
|
|
|
|
|
|
|
|
if (attno >= resultDesc->natts)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_DATATYPE_MISMATCH),
|
|
|
|
errmsg("table row type and query-specified row type do not match"),
|
|
|
|
errdetail("Query has too many columns.")));
|
|
|
|
attr = resultDesc->attrs[attno++];
|
|
|
|
|
|
|
|
if (!attr->attisdropped)
|
|
|
|
{
|
|
|
|
/* Normal case: demand type match */
|
|
|
|
if (exprType((Node *) tle->expr) != attr->atttypid)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_DATATYPE_MISMATCH),
|
|
|
|
errmsg("table row type and query-specified row type do not match"),
|
|
|
|
errdetail("Table has type %s at ordinal position %d, but query expects %s.",
|
|
|
|
format_type_be(attr->atttypid),
|
|
|
|
attno,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
format_type_be(exprType((Node *) tle->expr)))));
|
2009-10-10 03:43:50 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* For a dropped column, we can't check atttypid (it's likely 0).
|
|
|
|
* In any case the planner has most likely inserted an INT4 null.
|
|
|
|
* What we insist on is just *some* NULL constant.
|
|
|
|
*/
|
|
|
|
if (!IsA(tle->expr, Const) ||
|
|
|
|
!((Const *) tle->expr)->constisnull)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_DATATYPE_MISMATCH),
|
|
|
|
errmsg("table row type and query-specified row type do not match"),
|
|
|
|
errdetail("Query provides a value for a dropped column at ordinal position %d.",
|
|
|
|
attno)));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (attno != resultDesc->natts)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_DATATYPE_MISMATCH),
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
errmsg("table row type and query-specified row type do not match"),
|
2009-10-10 03:43:50 +02:00
|
|
|
errdetail("Query has too few columns.")));
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* ExecProcessReturning --- evaluate a RETURNING list
|
|
|
|
*
|
|
|
|
* projectReturning: RETURNING projection info for current result rel
|
|
|
|
* tupleSlot: slot holding tuple actually inserted/updated/deleted
|
|
|
|
* planSlot: slot holding tuple returned by top subplan node
|
|
|
|
*
|
2016-03-18 18:48:58 +01:00
|
|
|
* Note: If tupleSlot is NULL, the FDW should have already provided econtext's
|
|
|
|
* scan tuple.
|
|
|
|
*
|
2009-10-10 03:43:50 +02:00
|
|
|
* Returns a slot holding the result tuple
|
|
|
|
*/
|
|
|
|
static TupleTableSlot *
|
2016-03-18 18:48:58 +01:00
|
|
|
ExecProcessReturning(ResultRelInfo *resultRelInfo,
|
2009-10-10 03:43:50 +02:00
|
|
|
TupleTableSlot *tupleSlot,
|
|
|
|
TupleTableSlot *planSlot)
|
|
|
|
{
|
2016-03-18 18:48:58 +01:00
|
|
|
ProjectionInfo *projectReturning = resultRelInfo->ri_projectReturning;
|
2009-10-10 03:43:50 +02:00
|
|
|
ExprContext *econtext = projectReturning->pi_exprContext;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Reset per-tuple memory context to free any expression evaluation
|
|
|
|
* storage allocated in the previous cycle.
|
|
|
|
*/
|
|
|
|
ResetExprContext(econtext);
|
|
|
|
|
|
|
|
/* Make tuple and any needed join variables available to ExecProject */
|
2016-03-18 18:48:58 +01:00
|
|
|
if (tupleSlot)
|
|
|
|
econtext->ecxt_scantuple = tupleSlot;
|
|
|
|
else
|
|
|
|
{
|
|
|
|
HeapTuple tuple;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* RETURNING expressions might reference the tableoid column, so
|
|
|
|
* initialize t_tableOid before evaluating them.
|
|
|
|
*/
|
|
|
|
Assert(!TupIsNull(econtext->ecxt_scantuple));
|
|
|
|
tuple = ExecMaterializeSlot(econtext->ecxt_scantuple);
|
|
|
|
tuple->t_tableOid = RelationGetRelid(resultRelInfo->ri_RelationDesc);
|
|
|
|
}
|
2009-10-10 03:43:50 +02:00
|
|
|
econtext->ecxt_outertuple = planSlot;
|
|
|
|
|
|
|
|
/* Compute the RETURNING expressions */
|
2017-01-19 23:12:38 +01:00
|
|
|
return ExecProject(projectReturning);
|
2009-10-10 03:43:50 +02:00
|
|
|
}
|
|
|
|
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
/*
|
|
|
|
* ExecCheckHeapTupleVisible -- verify heap tuple is visible
|
|
|
|
*
|
|
|
|
* It would not be consistent with guarantees of the higher isolation levels to
|
|
|
|
* proceed with avoiding insertion (taking speculative insertion's alternative
|
|
|
|
* path) on the basis of another tuple that is not visible to MVCC snapshot.
|
|
|
|
* Check for the need to raise a serialization failure, and do so as necessary.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
ExecCheckHeapTupleVisible(EState *estate,
|
|
|
|
HeapTuple tuple,
|
|
|
|
Buffer buffer)
|
|
|
|
{
|
|
|
|
if (!IsolationUsesXactSnapshot())
|
|
|
|
return;
|
|
|
|
|
2016-10-24 01:14:32 +02:00
|
|
|
/*
|
|
|
|
* We need buffer pin and lock to call HeapTupleSatisfiesVisibility.
|
|
|
|
* Caller should be holding pin, but not lock.
|
|
|
|
*/
|
|
|
|
LockBuffer(buffer, BUFFER_LOCK_SHARE);
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
if (!HeapTupleSatisfiesVisibility(tuple, estate->es_snapshot, buffer))
|
2016-10-24 00:36:13 +02:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* We should not raise a serialization failure if the conflict is
|
|
|
|
* against a tuple inserted by our own transaction, even if it's not
|
|
|
|
* visible to our snapshot. (This would happen, for example, if
|
|
|
|
* conflicting keys are proposed for insertion in a single command.)
|
|
|
|
*/
|
|
|
|
if (!TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetXmin(tuple->t_data)))
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_T_R_SERIALIZATION_FAILURE),
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
errmsg("could not serialize access due to concurrent update")));
|
2016-10-24 00:36:13 +02:00
|
|
|
}
|
2016-10-24 01:14:32 +02:00
|
|
|
LockBuffer(buffer, BUFFER_LOCK_UNLOCK);
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* ExecCheckTIDVisible -- convenience variant of ExecCheckHeapTupleVisible()
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
ExecCheckTIDVisible(EState *estate,
|
|
|
|
ResultRelInfo *relinfo,
|
|
|
|
ItemPointer tid)
|
|
|
|
{
|
|
|
|
Relation rel = relinfo->ri_RelationDesc;
|
|
|
|
Buffer buffer;
|
|
|
|
HeapTupleData tuple;
|
|
|
|
|
|
|
|
/* Redundantly check isolation level */
|
|
|
|
if (!IsolationUsesXactSnapshot())
|
|
|
|
return;
|
|
|
|
|
|
|
|
tuple.t_self = *tid;
|
|
|
|
if (!heap_fetch(rel, SnapshotAny, &tuple, &buffer, false, NULL))
|
|
|
|
elog(ERROR, "failed to fetch conflicting tuple for ON CONFLICT");
|
|
|
|
ExecCheckHeapTupleVisible(estate, &tuple, buffer);
|
|
|
|
ReleaseBuffer(buffer);
|
|
|
|
}
|
|
|
|
|
2009-10-10 03:43:50 +02:00
|
|
|
/* ----------------------------------------------------------------
|
|
|
|
* ExecInsert
|
|
|
|
*
|
|
|
|
* For INSERT, we have to insert the tuple into the target relation
|
|
|
|
* and insert appropriate tuples into the index relations.
|
|
|
|
*
|
|
|
|
* Returns RETURNING result if any, otherwise NULL.
|
|
|
|
* ----------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
static TupleTableSlot *
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
ExecInsert(ModifyTableState *mtstate,
|
|
|
|
TupleTableSlot *slot,
|
2009-10-10 03:43:50 +02:00
|
|
|
TupleTableSlot *planSlot,
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
List *arbiterIndexes,
|
|
|
|
OnConflictAction onconflict,
|
2011-02-26 00:56:23 +01:00
|
|
|
EState *estate,
|
|
|
|
bool canSetTag)
|
2009-10-10 03:43:50 +02:00
|
|
|
{
|
|
|
|
HeapTuple tuple;
|
|
|
|
ResultRelInfo *resultRelInfo;
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
ResultRelInfo *saved_resultRelInfo = NULL;
|
2009-10-10 03:43:50 +02:00
|
|
|
Relation resultRelationDesc;
|
|
|
|
Oid newId;
|
|
|
|
List *recheckIndexes = NIL;
|
2017-04-10 18:20:08 +02:00
|
|
|
TupleTableSlot *result = NULL;
|
2009-10-10 03:43:50 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* get the heap tuple out of the tuple table slot, making sure we have a
|
|
|
|
* writable copy
|
|
|
|
*/
|
|
|
|
tuple = ExecMaterializeSlot(slot);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* get information on the (current) result relation
|
|
|
|
*/
|
|
|
|
resultRelInfo = estate->es_result_relation_info;
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
|
|
|
|
/* Determine the partition to heap_insert the tuple into */
|
|
|
|
if (mtstate->mt_partition_dispatch_info)
|
|
|
|
{
|
2017-01-24 16:20:02 +01:00
|
|
|
int leaf_part_index;
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
TupleConversionMap *map;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Away we go ... If we end up not finding a partition after all,
|
|
|
|
* ExecFindPartition() does not return and errors out instead.
|
2017-01-24 16:20:02 +01:00
|
|
|
* Otherwise, the returned value is to be used as an index into arrays
|
|
|
|
* mt_partitions[] and mt_partition_tupconv_maps[] that will get us
|
|
|
|
* the ResultRelInfo and TupleConversionMap for the partition,
|
|
|
|
* respectively.
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
*/
|
|
|
|
leaf_part_index = ExecFindPartition(resultRelInfo,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
mtstate->mt_partition_dispatch_info,
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
slot,
|
|
|
|
estate);
|
|
|
|
Assert(leaf_part_index >= 0 &&
|
|
|
|
leaf_part_index < mtstate->mt_num_partitions);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Save the old ResultRelInfo and switch to the one corresponding to
|
|
|
|
* the selected partition.
|
|
|
|
*/
|
|
|
|
saved_resultRelInfo = resultRelInfo;
|
|
|
|
resultRelInfo = mtstate->mt_partitions + leaf_part_index;
|
|
|
|
|
|
|
|
/* We do not yet have a way to insert into a foreign partition */
|
|
|
|
if (resultRelInfo->ri_FdwRoutine)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
errmsg("cannot route inserted tuples to a foreign table")));
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
|
|
|
|
/* For ExecInsertIndexTuples() to work on the partition's indexes */
|
|
|
|
estate->es_result_relation_info = resultRelInfo;
|
|
|
|
|
2017-06-28 19:55:03 +02:00
|
|
|
/*
|
|
|
|
* If we're capturing transition tuples, we might need to convert from
|
|
|
|
* the partition rowtype to parent rowtype.
|
|
|
|
*/
|
|
|
|
if (mtstate->mt_transition_capture != NULL)
|
|
|
|
{
|
|
|
|
if (resultRelInfo->ri_TrigDesc &&
|
|
|
|
(resultRelInfo->ri_TrigDesc->trig_insert_before_row ||
|
|
|
|
resultRelInfo->ri_TrigDesc->trig_insert_instead_row))
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* If there are any BEFORE or INSTEAD triggers on the
|
|
|
|
* partition, we'll have to be ready to convert their result
|
|
|
|
* back to tuplestore format.
|
|
|
|
*/
|
|
|
|
mtstate->mt_transition_capture->tcs_original_insert_tuple = NULL;
|
|
|
|
mtstate->mt_transition_capture->tcs_map =
|
|
|
|
mtstate->mt_transition_tupconv_maps[leaf_part_index];
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Otherwise, just remember the original unconverted tuple, to
|
|
|
|
* avoid a needless round trip conversion.
|
|
|
|
*/
|
|
|
|
mtstate->mt_transition_capture->tcs_original_insert_tuple = tuple;
|
|
|
|
mtstate->mt_transition_capture->tcs_map = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
/*
|
|
|
|
* We might need to convert from the parent rowtype to the partition
|
|
|
|
* rowtype.
|
|
|
|
*/
|
|
|
|
map = mtstate->mt_partition_tupconv_maps[leaf_part_index];
|
|
|
|
if (map)
|
|
|
|
{
|
2017-01-24 16:20:02 +01:00
|
|
|
Relation partrel = resultRelInfo->ri_RelationDesc;
|
2016-12-22 23:31:52 +01:00
|
|
|
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
tuple = do_convert_tuple(tuple, map);
|
2016-12-22 23:31:52 +01:00
|
|
|
|
|
|
|
/*
|
2017-01-24 16:20:02 +01:00
|
|
|
* We must use the partition's tuple descriptor from this point
|
|
|
|
* on, until we're finished dealing with the partition. Use the
|
|
|
|
* dedicated slot for that.
|
2016-12-22 23:31:52 +01:00
|
|
|
*/
|
2017-01-04 19:05:29 +01:00
|
|
|
slot = mtstate->mt_partition_tuple_slot;
|
2016-12-22 23:31:52 +01:00
|
|
|
Assert(slot != NULL);
|
|
|
|
ExecSetSlotDescriptor(slot, RelationGetDescr(partrel));
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
ExecStoreTuple(tuple, slot, InvalidBuffer, true);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-10-10 03:43:50 +02:00
|
|
|
resultRelationDesc = resultRelInfo->ri_RelationDesc;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the result relation has OIDs, force the tuple's OID to zero so that
|
|
|
|
* heap_insert will assign a fresh OID. Usually the OID already will be
|
|
|
|
* zero at this point, but there are corner cases where the plan tree can
|
|
|
|
* return a tuple extracted literally from some table with the same
|
|
|
|
* rowtype.
|
|
|
|
*
|
|
|
|
* XXX if we ever wanted to allow users to assign their own OIDs to new
|
|
|
|
* rows, this'd be the place to do it. For the moment, we make a point of
|
|
|
|
* doing this before calling triggers, so that a user-supplied trigger
|
|
|
|
* could hack the OID if desired.
|
|
|
|
*/
|
|
|
|
if (resultRelationDesc->rd_rel->relhasoids)
|
|
|
|
HeapTupleSetOid(tuple, InvalidOid);
|
|
|
|
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
/*
|
|
|
|
* BEFORE ROW INSERT Triggers.
|
|
|
|
*
|
|
|
|
* Note: We fire BEFORE ROW TRIGGERS for every attempted insertion in an
|
|
|
|
* INSERT ... ON CONFLICT statement. We cannot check for constraint
|
|
|
|
* violations before firing these triggers, because they can change the
|
|
|
|
* values to insert. Also, they can run arbitrary user-defined code with
|
|
|
|
* side-effects that we can't cancel by just not inserting the tuple.
|
|
|
|
*/
|
2009-10-10 03:43:50 +02:00
|
|
|
if (resultRelInfo->ri_TrigDesc &&
|
2010-10-10 19:43:33 +02:00
|
|
|
resultRelInfo->ri_TrigDesc->trig_insert_before_row)
|
2009-10-10 03:43:50 +02:00
|
|
|
{
|
2011-02-22 03:18:04 +01:00
|
|
|
slot = ExecBRInsertTriggers(estate, resultRelInfo, slot);
|
2009-10-10 03:43:50 +02:00
|
|
|
|
2011-02-22 03:18:04 +01:00
|
|
|
if (slot == NULL) /* "do nothing" */
|
2009-10-10 03:43:50 +02:00
|
|
|
return NULL;
|
|
|
|
|
2011-02-22 03:18:04 +01:00
|
|
|
/* trigger might have changed tuple */
|
|
|
|
tuple = ExecMaterializeSlot(slot);
|
2009-10-10 03:43:50 +02:00
|
|
|
}
|
|
|
|
|
2010-10-10 19:43:33 +02:00
|
|
|
/* INSTEAD OF ROW INSERT Triggers */
|
|
|
|
if (resultRelInfo->ri_TrigDesc &&
|
|
|
|
resultRelInfo->ri_TrigDesc->trig_insert_instead_row)
|
|
|
|
{
|
2011-02-22 03:18:04 +01:00
|
|
|
slot = ExecIRInsertTriggers(estate, resultRelInfo, slot);
|
2009-10-10 03:43:50 +02:00
|
|
|
|
2011-02-22 03:18:04 +01:00
|
|
|
if (slot == NULL) /* "do nothing" */
|
2010-10-10 19:43:33 +02:00
|
|
|
return NULL;
|
|
|
|
|
2011-02-22 03:18:04 +01:00
|
|
|
/* trigger might have changed tuple */
|
|
|
|
tuple = ExecMaterializeSlot(slot);
|
2010-10-10 19:43:33 +02:00
|
|
|
|
|
|
|
newId = InvalidOid;
|
|
|
|
}
|
2013-03-10 19:14:53 +01:00
|
|
|
else if (resultRelInfo->ri_FdwRoutine)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* insert into foreign table: let the FDW do it
|
|
|
|
*/
|
|
|
|
slot = resultRelInfo->ri_FdwRoutine->ExecForeignInsert(estate,
|
|
|
|
resultRelInfo,
|
|
|
|
slot,
|
|
|
|
planSlot);
|
|
|
|
|
|
|
|
if (slot == NULL) /* "do nothing" */
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
/* FDW might have changed tuple */
|
|
|
|
tuple = ExecMaterializeSlot(slot);
|
|
|
|
|
2016-02-05 03:15:57 +01:00
|
|
|
/*
|
|
|
|
* AFTER ROW Triggers or RETURNING expressions might reference the
|
|
|
|
* tableoid column, so initialize t_tableOid before evaluating them.
|
|
|
|
*/
|
|
|
|
tuple->t_tableOid = RelationGetRelid(resultRelationDesc);
|
|
|
|
|
2013-03-10 19:14:53 +01:00
|
|
|
newId = InvalidOid;
|
|
|
|
}
|
2010-10-10 19:43:33 +02:00
|
|
|
else
|
|
|
|
{
|
2017-06-07 18:45:32 +02:00
|
|
|
/*
|
|
|
|
* We always check the partition constraint, including when the tuple
|
|
|
|
* got here via tuple-routing. However we don't need to in the latter
|
|
|
|
* case if no BR trigger is defined on the partition. Note that a BR
|
|
|
|
* trigger might modify the tuple such that the partition constraint
|
|
|
|
* is no longer satisfied, so we need to check in that case.
|
|
|
|
*/
|
2017-06-13 19:05:59 +02:00
|
|
|
bool check_partition_constr =
|
|
|
|
(resultRelInfo->ri_PartitionCheck != NIL);
|
2017-06-07 18:45:32 +02:00
|
|
|
|
Don't allow system columns in CHECK constraints, except tableoid.
Previously, arbitray system columns could be mentioned in table
constraints, but they were not correctly checked at runtime, because
the values weren't actually set correctly in the tuple. Since it
seems easy enough to initialize the table OID properly, do that,
and continue allowing that column, but disallow the rest unless and
until someone figures out a way to make them work properly.
No back-patch, because this doesn't seem important enough to take the
risk of destabilizing the back branches. In fact, this will pose a
dump-and-reload hazard for those upgrading from previous versions:
constraints that were accepted before but were not correctly enforced
will now either be enforced correctly or not accepted at all. Either
could result in restore failures, but in practice I think very few
users will notice the difference, since the use case is pretty
marginal anyway and few users will be relying on features that have
not historically worked.
Amit Kapila, reviewed by Rushabh Lathia, with doc changes by me.
2013-09-23 19:31:22 +02:00
|
|
|
/*
|
|
|
|
* Constraints might reference the tableoid column, so initialize
|
|
|
|
* t_tableOid before evaluating them.
|
|
|
|
*/
|
|
|
|
tuple->t_tableOid = RelationGetRelid(resultRelationDesc);
|
|
|
|
|
2015-04-25 02:34:26 +02:00
|
|
|
/*
|
|
|
|
* Check any RLS INSERT WITH CHECK policies
|
|
|
|
*
|
2015-05-24 03:35:49 +02:00
|
|
|
* ExecWithCheckOptions() will skip any WCOs which are not of the kind
|
|
|
|
* we are looking for at this point.
|
2015-04-25 02:34:26 +02:00
|
|
|
*/
|
|
|
|
if (resultRelInfo->ri_WithCheckOptions != NIL)
|
|
|
|
ExecWithCheckOptions(WCO_RLS_INSERT_CHECK,
|
|
|
|
resultRelInfo, slot, estate);
|
|
|
|
|
2010-10-10 19:43:33 +02:00
|
|
|
/*
|
2017-06-07 18:45:32 +02:00
|
|
|
* No need though if the tuple has been routed, and a BR trigger
|
|
|
|
* doesn't exist.
|
2010-10-10 19:43:33 +02:00
|
|
|
*/
|
2017-06-07 18:45:32 +02:00
|
|
|
if (saved_resultRelInfo != NULL &&
|
|
|
|
!(resultRelInfo->ri_TrigDesc &&
|
|
|
|
resultRelInfo->ri_TrigDesc->trig_insert_before_row))
|
|
|
|
check_partition_constr = false;
|
|
|
|
|
|
|
|
/* Check the constraints of the tuple */
|
|
|
|
if (resultRelationDesc->rd_att->constr || check_partition_constr)
|
2017-04-10 18:20:08 +02:00
|
|
|
ExecConstraints(resultRelInfo, slot, estate);
|
2010-10-10 19:43:33 +02:00
|
|
|
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
if (onconflict != ONCONFLICT_NONE && resultRelInfo->ri_NumIndices > 0)
|
|
|
|
{
|
|
|
|
/* Perform a speculative insertion. */
|
|
|
|
uint32 specToken;
|
|
|
|
ItemPointerData conflictTid;
|
|
|
|
bool specConflict;
|
2010-10-10 19:43:33 +02:00
|
|
|
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
/*
|
|
|
|
* Do a non-conclusive check for conflicts first.
|
|
|
|
*
|
|
|
|
* We're not holding any locks yet, so this doesn't guarantee that
|
|
|
|
* the later insert won't conflict. But it avoids leaving behind
|
|
|
|
* a lot of canceled speculative insertions, if you run a lot of
|
|
|
|
* INSERT ON CONFLICT statements that do conflict.
|
|
|
|
*
|
|
|
|
* We loop back here if we find a conflict below, either during
|
|
|
|
* the pre-check, or when we re-check after inserting the tuple
|
2015-07-27 10:46:11 +02:00
|
|
|
* speculatively.
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
*/
|
|
|
|
vlock:
|
|
|
|
specConflict = false;
|
|
|
|
if (!ExecCheckIndexConstraints(slot, estate, &conflictTid,
|
|
|
|
arbiterIndexes))
|
|
|
|
{
|
|
|
|
/* committed conflict tuple found */
|
|
|
|
if (onconflict == ONCONFLICT_UPDATE)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* In case of ON CONFLICT DO UPDATE, execute the UPDATE
|
|
|
|
* part. Be prepared to retry if the UPDATE fails because
|
|
|
|
* of another concurrent UPDATE/DELETE to the conflict
|
|
|
|
* tuple.
|
|
|
|
*/
|
|
|
|
TupleTableSlot *returning = NULL;
|
|
|
|
|
|
|
|
if (ExecOnConflictUpdate(mtstate, resultRelInfo,
|
|
|
|
&conflictTid, planSlot, slot,
|
|
|
|
estate, canSetTag, &returning))
|
|
|
|
{
|
|
|
|
InstrCountFiltered2(&mtstate->ps, 1);
|
|
|
|
return returning;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
goto vlock;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/*
|
2015-05-24 03:35:49 +02:00
|
|
|
* In case of ON CONFLICT DO NOTHING, do nothing. However,
|
|
|
|
* verify that the tuple is visible to the executor's MVCC
|
|
|
|
* snapshot at higher isolation levels.
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
*/
|
|
|
|
Assert(onconflict == ONCONFLICT_NOTHING);
|
|
|
|
ExecCheckTIDVisible(estate, resultRelInfo, &conflictTid);
|
|
|
|
InstrCountFiltered2(&mtstate->ps, 1);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Before we start insertion proper, acquire our "speculative
|
|
|
|
* insertion lock". Others can use that to wait for us to decide
|
|
|
|
* if we're going to go ahead with the insertion, instead of
|
|
|
|
* waiting for the whole transaction to complete.
|
|
|
|
*/
|
|
|
|
specToken = SpeculativeInsertionLockAcquire(GetCurrentTransactionId());
|
|
|
|
HeapTupleHeaderSetSpeculativeToken(tuple->t_data, specToken);
|
|
|
|
|
|
|
|
/* insert the tuple, with the speculative token */
|
|
|
|
newId = heap_insert(resultRelationDesc, tuple,
|
|
|
|
estate->es_output_cid,
|
|
|
|
HEAP_INSERT_SPECULATIVE,
|
|
|
|
NULL);
|
|
|
|
|
|
|
|
/* insert index entries for tuple */
|
2010-10-10 19:43:33 +02:00
|
|
|
recheckIndexes = ExecInsertIndexTuples(slot, &(tuple->t_self),
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
estate, true, &specConflict,
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
arbiterIndexes);
|
|
|
|
|
|
|
|
/* adjust the tuple's state accordingly */
|
|
|
|
if (!specConflict)
|
|
|
|
heap_finish_speculative(resultRelationDesc, tuple);
|
|
|
|
else
|
|
|
|
heap_abort_speculative(resultRelationDesc, tuple);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Wake up anyone waiting for our decision. They will re-check
|
|
|
|
* the tuple, see that it's no longer speculative, and wait on our
|
|
|
|
* XID as if this was a regularly inserted tuple all along. Or if
|
|
|
|
* we killed the tuple, they will see it's dead, and proceed as if
|
|
|
|
* the tuple never existed.
|
|
|
|
*/
|
|
|
|
SpeculativeInsertionLockRelease(GetCurrentTransactionId());
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If there was a conflict, start from the beginning. We'll do
|
|
|
|
* the pre-check again, which will now find the conflicting tuple
|
|
|
|
* (unless it aborts before we get there).
|
|
|
|
*/
|
|
|
|
if (specConflict)
|
|
|
|
{
|
|
|
|
list_free(recheckIndexes);
|
|
|
|
goto vlock;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Since there was no insertion conflict, we're done */
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* insert the tuple normally.
|
|
|
|
*
|
|
|
|
* Note: heap_insert returns the tid (location) of the new tuple
|
|
|
|
* in the t_self field.
|
|
|
|
*/
|
|
|
|
newId = heap_insert(resultRelationDesc, tuple,
|
|
|
|
estate->es_output_cid,
|
|
|
|
0, NULL);
|
|
|
|
|
|
|
|
/* insert index entries for tuple */
|
|
|
|
if (resultRelInfo->ri_NumIndices > 0)
|
|
|
|
recheckIndexes = ExecInsertIndexTuples(slot, &(tuple->t_self),
|
|
|
|
estate, false, NULL,
|
|
|
|
arbiterIndexes);
|
|
|
|
}
|
2010-10-10 19:43:33 +02:00
|
|
|
}
|
2009-10-10 03:43:50 +02:00
|
|
|
|
2011-02-26 00:56:23 +01:00
|
|
|
if (canSetTag)
|
|
|
|
{
|
|
|
|
(estate->es_processed)++;
|
|
|
|
estate->es_lastoid = newId;
|
|
|
|
setLastTid(&(tuple->t_self));
|
|
|
|
}
|
2009-10-10 03:43:50 +02:00
|
|
|
|
|
|
|
/* AFTER ROW INSERT Triggers */
|
2017-06-28 19:55:03 +02:00
|
|
|
ExecARInsertTriggers(estate, resultRelInfo, tuple, recheckIndexes,
|
|
|
|
mtstate->mt_transition_capture);
|
2009-10-10 03:43:50 +02:00
|
|
|
|
2010-01-31 19:15:39 +01:00
|
|
|
list_free(recheckIndexes);
|
|
|
|
|
2015-04-25 02:34:26 +02:00
|
|
|
/*
|
2015-05-24 03:35:49 +02:00
|
|
|
* Check any WITH CHECK OPTION constraints from parent views. We are
|
|
|
|
* required to do this after testing all constraints and uniqueness
|
|
|
|
* violations per the SQL spec, so we do it after actually inserting the
|
|
|
|
* record into the heap and all indexes.
|
2015-04-25 02:34:26 +02:00
|
|
|
*
|
2015-05-24 03:35:49 +02:00
|
|
|
* ExecWithCheckOptions will elog(ERROR) if a violation is found, so the
|
|
|
|
* tuple will never be seen, if it violates the WITH CHECK OPTION.
|
2015-04-25 02:34:26 +02:00
|
|
|
*
|
2015-05-24 03:35:49 +02:00
|
|
|
* ExecWithCheckOptions() will skip any WCOs which are not of the kind we
|
|
|
|
* are looking for at this point.
|
2015-04-25 02:34:26 +02:00
|
|
|
*/
|
2013-07-18 23:10:16 +02:00
|
|
|
if (resultRelInfo->ri_WithCheckOptions != NIL)
|
2015-04-25 02:34:26 +02:00
|
|
|
ExecWithCheckOptions(WCO_VIEW_CHECK, resultRelInfo, slot, estate);
|
2013-07-18 23:10:16 +02:00
|
|
|
|
2009-10-10 03:43:50 +02:00
|
|
|
/* Process RETURNING if present */
|
|
|
|
if (resultRelInfo->ri_projectReturning)
|
2017-01-19 19:20:11 +01:00
|
|
|
result = ExecProcessReturning(resultRelInfo, slot, planSlot);
|
2009-10-10 03:43:50 +02:00
|
|
|
|
2017-01-19 19:20:11 +01:00
|
|
|
if (saved_resultRelInfo)
|
|
|
|
estate->es_result_relation_info = saved_resultRelInfo;
|
|
|
|
|
|
|
|
return result;
|
2009-10-10 03:43:50 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* ----------------------------------------------------------------
|
|
|
|
* ExecDelete
|
|
|
|
*
|
|
|
|
* DELETE is like UPDATE, except that we delete the tuple and no
|
2010-10-10 19:43:33 +02:00
|
|
|
* index modifications are needed.
|
|
|
|
*
|
|
|
|
* When deleting from a table, tupleid identifies the tuple to
|
|
|
|
* delete and oldtuple is NULL. When deleting from a view,
|
|
|
|
* oldtuple is passed to the INSTEAD OF triggers and identifies
|
2013-03-10 19:14:53 +01:00
|
|
|
* what to delete, and tupleid is invalid. When deleting from a
|
2014-03-23 07:16:34 +01:00
|
|
|
* foreign table, tupleid is invalid; the FDW has to figure out
|
|
|
|
* which row to delete using data from the planSlot. oldtuple is
|
|
|
|
* passed to foreign table triggers; it is NULL when the foreign
|
|
|
|
* table has no relevant triggers.
|
2009-10-10 03:43:50 +02:00
|
|
|
*
|
|
|
|
* Returns RETURNING result if any, otherwise NULL.
|
|
|
|
* ----------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
static TupleTableSlot *
|
2017-06-28 19:55:03 +02:00
|
|
|
ExecDelete(ModifyTableState *mtstate,
|
|
|
|
ItemPointer tupleid,
|
2014-03-23 07:16:34 +01:00
|
|
|
HeapTuple oldtuple,
|
2009-10-10 03:43:50 +02:00
|
|
|
TupleTableSlot *planSlot,
|
Re-implement EvalPlanQual processing to improve its performance and eliminate
a lot of strange behaviors that occurred in join cases. We now identify the
"current" row for every joined relation in UPDATE, DELETE, and SELECT FOR
UPDATE/SHARE queries. If an EvalPlanQual recheck is necessary, we jam the
appropriate row into each scan node in the rechecking plan, forcing it to emit
only that one row. The former behavior could rescan the whole of each joined
relation for each recheck, which was terrible for performance, and what's much
worse could result in duplicated output tuples.
Also, the original implementation of EvalPlanQual could not re-use the recheck
execution tree --- it had to go through a full executor init and shutdown for
every row to be tested. To avoid this overhead, I've associated a special
runtime Param with each LockRows or ModifyTable plan node, and arranged to
make every scan node below such a node depend on that Param. Thus, by
signaling a change in that Param, the EPQ machinery can just rescan the
already-built test plan.
This patch also adds a prohibition on set-returning functions in the
targetlist of SELECT FOR UPDATE/SHARE. This is needed to avoid the
duplicate-output-tuple problem. It seems fairly reasonable since the
other restrictions on SELECT FOR UPDATE are meant to ensure that there
is a unique correspondence between source tuples and result tuples,
which an output SRF destroys as much as anything else does.
2009-10-26 03:26:45 +01:00
|
|
|
EPQState *epqstate,
|
2011-02-26 00:56:23 +01:00
|
|
|
EState *estate,
|
|
|
|
bool canSetTag)
|
2009-10-10 03:43:50 +02:00
|
|
|
{
|
|
|
|
ResultRelInfo *resultRelInfo;
|
|
|
|
Relation resultRelationDesc;
|
|
|
|
HTSU_Result result;
|
2012-10-26 21:55:36 +02:00
|
|
|
HeapUpdateFailureData hufd;
|
2013-03-10 19:14:53 +01:00
|
|
|
TupleTableSlot *slot = NULL;
|
2009-10-10 03:43:50 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* get information on the (current) result relation
|
|
|
|
*/
|
|
|
|
resultRelInfo = estate->es_result_relation_info;
|
|
|
|
resultRelationDesc = resultRelInfo->ri_RelationDesc;
|
|
|
|
|
|
|
|
/* BEFORE ROW DELETE Triggers */
|
|
|
|
if (resultRelInfo->ri_TrigDesc &&
|
2010-10-10 19:43:33 +02:00
|
|
|
resultRelInfo->ri_TrigDesc->trig_delete_before_row)
|
2009-10-10 03:43:50 +02:00
|
|
|
{
|
|
|
|
bool dodelete;
|
|
|
|
|
Re-implement EvalPlanQual processing to improve its performance and eliminate
a lot of strange behaviors that occurred in join cases. We now identify the
"current" row for every joined relation in UPDATE, DELETE, and SELECT FOR
UPDATE/SHARE queries. If an EvalPlanQual recheck is necessary, we jam the
appropriate row into each scan node in the rechecking plan, forcing it to emit
only that one row. The former behavior could rescan the whole of each joined
relation for each recheck, which was terrible for performance, and what's much
worse could result in duplicated output tuples.
Also, the original implementation of EvalPlanQual could not re-use the recheck
execution tree --- it had to go through a full executor init and shutdown for
every row to be tested. To avoid this overhead, I've associated a special
runtime Param with each LockRows or ModifyTable plan node, and arranged to
make every scan node below such a node depend on that Param. Thus, by
signaling a change in that Param, the EPQ machinery can just rescan the
already-built test plan.
This patch also adds a prohibition on set-returning functions in the
targetlist of SELECT FOR UPDATE/SHARE. This is needed to avoid the
duplicate-output-tuple problem. It seems fairly reasonable since the
other restrictions on SELECT FOR UPDATE are meant to ensure that there
is a unique correspondence between source tuples and result tuples,
which an output SRF destroys as much as anything else does.
2009-10-26 03:26:45 +01:00
|
|
|
dodelete = ExecBRDeleteTriggers(estate, epqstate, resultRelInfo,
|
2014-03-23 07:16:34 +01:00
|
|
|
tupleid, oldtuple);
|
2009-10-10 03:43:50 +02:00
|
|
|
|
|
|
|
if (!dodelete) /* "do nothing" */
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2010-10-10 19:43:33 +02:00
|
|
|
/* INSTEAD OF ROW DELETE Triggers */
|
|
|
|
if (resultRelInfo->ri_TrigDesc &&
|
|
|
|
resultRelInfo->ri_TrigDesc->trig_delete_instead_row)
|
2009-10-10 03:43:50 +02:00
|
|
|
{
|
2010-10-10 19:43:33 +02:00
|
|
|
bool dodelete;
|
|
|
|
|
|
|
|
Assert(oldtuple != NULL);
|
2014-03-23 07:16:34 +01:00
|
|
|
dodelete = ExecIRDeleteTriggers(estate, resultRelInfo, oldtuple);
|
2010-10-10 19:43:33 +02:00
|
|
|
|
|
|
|
if (!dodelete) /* "do nothing" */
|
2009-10-10 03:43:50 +02:00
|
|
|
return NULL;
|
2010-10-10 19:43:33 +02:00
|
|
|
}
|
2013-03-10 19:14:53 +01:00
|
|
|
else if (resultRelInfo->ri_FdwRoutine)
|
|
|
|
{
|
2016-02-05 03:15:57 +01:00
|
|
|
HeapTuple tuple;
|
|
|
|
|
2013-03-10 19:14:53 +01:00
|
|
|
/*
|
|
|
|
* delete from foreign table: let the FDW do it
|
|
|
|
*
|
|
|
|
* We offer the trigger tuple slot as a place to store RETURNING data,
|
|
|
|
* although the FDW can return some other slot if it wants. Set up
|
|
|
|
* the slot's tupdesc so the FDW doesn't need to do that for itself.
|
|
|
|
*/
|
|
|
|
slot = estate->es_trig_tuple_slot;
|
|
|
|
if (slot->tts_tupleDescriptor != RelationGetDescr(resultRelationDesc))
|
|
|
|
ExecSetSlotDescriptor(slot, RelationGetDescr(resultRelationDesc));
|
|
|
|
|
|
|
|
slot = resultRelInfo->ri_FdwRoutine->ExecForeignDelete(estate,
|
|
|
|
resultRelInfo,
|
|
|
|
slot,
|
|
|
|
planSlot);
|
|
|
|
|
|
|
|
if (slot == NULL) /* "do nothing" */
|
|
|
|
return NULL;
|
2016-02-05 03:15:57 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* RETURNING expressions might reference the tableoid column, so
|
|
|
|
* initialize t_tableOid before evaluating them.
|
|
|
|
*/
|
|
|
|
if (slot->tts_isempty)
|
|
|
|
ExecStoreAllNullTuple(slot);
|
|
|
|
tuple = ExecMaterializeSlot(slot);
|
|
|
|
tuple->t_tableOid = RelationGetRelid(resultRelationDesc);
|
2013-03-10 19:14:53 +01:00
|
|
|
}
|
2010-10-10 19:43:33 +02:00
|
|
|
else
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* delete the tuple
|
|
|
|
*
|
|
|
|
* Note: if es_crosscheck_snapshot isn't InvalidSnapshot, we check
|
|
|
|
* that the row to be deleted is visible to that snapshot, and throw a
|
|
|
|
* can't-serialize error if not. This is a special-case behavior
|
|
|
|
* needed for referential integrity updates in transaction-snapshot
|
|
|
|
* mode transactions.
|
|
|
|
*/
|
|
|
|
ldelete:;
|
|
|
|
result = heap_delete(resultRelationDesc, tupleid,
|
|
|
|
estate->es_output_cid,
|
|
|
|
estate->es_crosscheck_snapshot,
|
2013-05-29 22:58:43 +02:00
|
|
|
true /* wait for commit */ ,
|
2012-10-26 21:55:36 +02:00
|
|
|
&hufd);
|
2010-10-10 19:43:33 +02:00
|
|
|
switch (result)
|
|
|
|
{
|
|
|
|
case HeapTupleSelfUpdated:
|
2013-05-29 22:58:43 +02:00
|
|
|
|
2012-10-26 21:55:36 +02:00
|
|
|
/*
|
|
|
|
* The target tuple was already updated or deleted by the
|
|
|
|
* current command, or by a later command in the current
|
|
|
|
* transaction. The former case is possible in a join DELETE
|
2013-05-29 22:58:43 +02:00
|
|
|
* where multiple tuples join to the same target tuple. This
|
|
|
|
* is somewhat questionable, but Postgres has always allowed
|
|
|
|
* it: we just ignore additional deletion attempts.
|
2012-10-26 21:55:36 +02:00
|
|
|
*
|
|
|
|
* The latter case arises if the tuple is modified by a
|
|
|
|
* command in a BEFORE trigger, or perhaps by a command in a
|
|
|
|
* volatile function used in the query. In such situations we
|
|
|
|
* should not ignore the deletion, but it is equally unsafe to
|
|
|
|
* proceed. We don't want to discard the original DELETE
|
|
|
|
* while keeping the triggered actions based on its deletion;
|
|
|
|
* and it would be no better to allow the original DELETE
|
2014-05-06 18:12:18 +02:00
|
|
|
* while discarding updates that it triggered. The row update
|
2012-10-26 21:55:36 +02:00
|
|
|
* carries some information that might be important according
|
|
|
|
* to business rules; so throwing an error is the only safe
|
|
|
|
* course.
|
|
|
|
*
|
2013-05-29 22:58:43 +02:00
|
|
|
* If a trigger actually intends this type of interaction, it
|
|
|
|
* can re-execute the DELETE and then return NULL to cancel
|
|
|
|
* the outer delete.
|
2012-10-26 21:55:36 +02:00
|
|
|
*/
|
|
|
|
if (hufd.cmax != estate->es_output_cid)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_TRIGGERED_DATA_CHANGE_VIOLATION),
|
|
|
|
errmsg("tuple to be updated was already modified by an operation triggered by the current command"),
|
|
|
|
errhint("Consider using an AFTER trigger instead of a BEFORE trigger to propagate changes to other rows.")));
|
|
|
|
|
|
|
|
/* Else, already deleted by self; nothing to do */
|
2010-10-10 19:43:33 +02:00
|
|
|
return NULL;
|
2009-10-10 03:43:50 +02:00
|
|
|
|
2010-10-10 19:43:33 +02:00
|
|
|
case HeapTupleMayBeUpdated:
|
|
|
|
break;
|
2009-10-10 03:43:50 +02:00
|
|
|
|
2010-10-10 19:43:33 +02:00
|
|
|
case HeapTupleUpdated:
|
|
|
|
if (IsolationUsesXactSnapshot())
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_T_R_SERIALIZATION_FAILURE),
|
|
|
|
errmsg("could not serialize access due to concurrent update")));
|
2012-10-26 21:55:36 +02:00
|
|
|
if (!ItemPointerEquals(tupleid, &hufd.ctid))
|
2009-10-10 03:43:50 +02:00
|
|
|
{
|
2010-10-10 19:43:33 +02:00
|
|
|
TupleTableSlot *epqslot;
|
|
|
|
|
|
|
|
epqslot = EvalPlanQual(estate,
|
|
|
|
epqstate,
|
|
|
|
resultRelationDesc,
|
|
|
|
resultRelInfo->ri_RangeTableIndex,
|
Improve concurrency of foreign key locking
This patch introduces two additional lock modes for tuples: "SELECT FOR
KEY SHARE" and "SELECT FOR NO KEY UPDATE". These don't block each
other, in contrast with already existing "SELECT FOR SHARE" and "SELECT
FOR UPDATE". UPDATE commands that do not modify the values stored in
the columns that are part of the key of the tuple now grab a SELECT FOR
NO KEY UPDATE lock on the tuple, allowing them to proceed concurrently
with tuple locks of the FOR KEY SHARE variety.
Foreign key triggers now use FOR KEY SHARE instead of FOR SHARE; this
means the concurrency improvement applies to them, which is the whole
point of this patch.
The added tuple lock semantics require some rejiggering of the multixact
module, so that the locking level that each transaction is holding can
be stored alongside its Xid. Also, multixacts now need to persist
across server restarts and crashes, because they can now represent not
only tuple locks, but also tuple updates. This means we need more
careful tracking of lifetime of pg_multixact SLRU files; since they now
persist longer, we require more infrastructure to figure out when they
can be removed. pg_upgrade also needs to be careful to copy
pg_multixact files over from the old server to the new, or at least part
of multixact.c state, depending on the versions of the old and new
servers.
Tuple time qualification rules (HeapTupleSatisfies routines) need to be
careful not to consider tuples with the "is multi" infomask bit set as
being only locked; they might need to look up MultiXact values (i.e.
possibly do pg_multixact I/O) to find out the Xid that updated a tuple,
whereas they previously were assured to only use information readily
available from the tuple header. This is considered acceptable, because
the extra I/O would involve cases that would previously cause some
commands to block waiting for concurrent transactions to finish.
Another important change is the fact that locking tuples that have
previously been updated causes the future versions to be marked as
locked, too; this is essential for correctness of foreign key checks.
This causes additional WAL-logging, also (there was previously a single
WAL record for a locked tuple; now there are as many as updated copies
of the tuple there exist.)
With all this in place, contention related to tuples being checked by
foreign key rules should be much reduced.
As a bonus, the old behavior that a subtransaction grabbing a stronger
tuple lock than the parent (sub)transaction held on a given tuple and
later aborting caused the weaker lock to be lost, has been fixed.
Many new spec files were added for isolation tester framework, to ensure
overall behavior is sane. There's probably room for several more tests.
There were several reviewers of this patch; in particular, Noah Misch
and Andres Freund spent considerable time in it. Original idea for the
patch came from Simon Riggs, after a problem report by Joel Jacobson.
Most code is from me, with contributions from Marti Raudsepp, Alexander
Shulgin, Noah Misch and Andres Freund.
This patch was discussed in several pgsql-hackers threads; the most
important start at the following message-ids:
AANLkTimo9XVcEzfiBR-ut3KVNDkjm2Vxh+t8kAmWjPuv@mail.gmail.com
1290721684-sup-3951@alvh.no-ip.org
1294953201-sup-2099@alvh.no-ip.org
1320343602-sup-2290@alvh.no-ip.org
1339690386-sup-8927@alvh.no-ip.org
4FE5FF020200002500048A3D@gw.wicourts.gov
4FEAB90A0200002500048B7D@gw.wicourts.gov
2013-01-23 16:04:59 +01:00
|
|
|
LockTupleExclusive,
|
2012-10-26 21:55:36 +02:00
|
|
|
&hufd.ctid,
|
|
|
|
hufd.xmax);
|
2010-10-10 19:43:33 +02:00
|
|
|
if (!TupIsNull(epqslot))
|
|
|
|
{
|
2012-10-26 21:55:36 +02:00
|
|
|
*tupleid = hufd.ctid;
|
2010-10-10 19:43:33 +02:00
|
|
|
goto ldelete;
|
|
|
|
}
|
2009-10-10 03:43:50 +02:00
|
|
|
}
|
2010-10-10 19:43:33 +02:00
|
|
|
/* tuple already deleted; nothing to do */
|
|
|
|
return NULL;
|
2009-10-10 03:43:50 +02:00
|
|
|
|
2010-10-10 19:43:33 +02:00
|
|
|
default:
|
|
|
|
elog(ERROR, "unrecognized heap_delete status: %u", result);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Note: Normally one would think that we have to delete index tuples
|
|
|
|
* associated with the heap tuple now...
|
|
|
|
*
|
|
|
|
* ... but in POSTGRES, we have no need to do this because VACUUM will
|
|
|
|
* take care of it later. We can't delete index tuples immediately
|
|
|
|
* anyway, since the tuple is still visible to other transactions.
|
|
|
|
*/
|
2009-10-10 03:43:50 +02:00
|
|
|
}
|
|
|
|
|
2011-02-26 00:56:23 +01:00
|
|
|
if (canSetTag)
|
|
|
|
(estate->es_processed)++;
|
2009-10-10 03:43:50 +02:00
|
|
|
|
|
|
|
/* AFTER ROW DELETE Triggers */
|
2017-06-28 19:55:03 +02:00
|
|
|
ExecARDeleteTriggers(estate, resultRelInfo, tupleid, oldtuple,
|
|
|
|
mtstate->mt_transition_capture);
|
2009-10-10 03:43:50 +02:00
|
|
|
|
|
|
|
/* Process RETURNING if present */
|
|
|
|
if (resultRelInfo->ri_projectReturning)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* We have to put the target tuple into a slot, which means first we
|
2014-05-06 18:12:18 +02:00
|
|
|
* gotta fetch it. We can use the trigger tuple slot.
|
2009-10-10 03:43:50 +02:00
|
|
|
*/
|
|
|
|
TupleTableSlot *rslot;
|
|
|
|
HeapTupleData deltuple;
|
|
|
|
Buffer delbuffer;
|
|
|
|
|
2013-03-10 19:14:53 +01:00
|
|
|
if (resultRelInfo->ri_FdwRoutine)
|
2010-10-10 19:43:33 +02:00
|
|
|
{
|
2013-03-10 19:14:53 +01:00
|
|
|
/* FDW must have provided a slot containing the deleted row */
|
|
|
|
Assert(!TupIsNull(slot));
|
2010-10-10 19:43:33 +02:00
|
|
|
delbuffer = InvalidBuffer;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2013-03-10 19:14:53 +01:00
|
|
|
slot = estate->es_trig_tuple_slot;
|
|
|
|
if (oldtuple != NULL)
|
|
|
|
{
|
2014-03-23 07:16:34 +01:00
|
|
|
deltuple = *oldtuple;
|
2013-03-10 19:14:53 +01:00
|
|
|
delbuffer = InvalidBuffer;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
deltuple.t_self = *tupleid;
|
|
|
|
if (!heap_fetch(resultRelationDesc, SnapshotAny,
|
|
|
|
&deltuple, &delbuffer, false, NULL))
|
|
|
|
elog(ERROR, "failed to fetch deleted tuple for DELETE RETURNING");
|
|
|
|
}
|
2009-10-10 03:43:50 +02:00
|
|
|
|
2013-03-10 19:14:53 +01:00
|
|
|
if (slot->tts_tupleDescriptor != RelationGetDescr(resultRelationDesc))
|
|
|
|
ExecSetSlotDescriptor(slot, RelationGetDescr(resultRelationDesc));
|
|
|
|
ExecStoreTuple(&deltuple, slot, InvalidBuffer, false);
|
|
|
|
}
|
2009-10-10 03:43:50 +02:00
|
|
|
|
2016-03-18 18:48:58 +01:00
|
|
|
rslot = ExecProcessReturning(resultRelInfo, slot, planSlot);
|
2009-10-10 03:43:50 +02:00
|
|
|
|
2013-03-10 19:14:53 +01:00
|
|
|
/*
|
|
|
|
* Before releasing the target tuple again, make sure rslot has a
|
|
|
|
* local copy of any pass-by-reference values.
|
|
|
|
*/
|
|
|
|
ExecMaterializeSlot(rslot);
|
|
|
|
|
2009-10-10 03:43:50 +02:00
|
|
|
ExecClearTuple(slot);
|
2010-10-10 19:43:33 +02:00
|
|
|
if (BufferIsValid(delbuffer))
|
|
|
|
ReleaseBuffer(delbuffer);
|
2009-10-10 03:43:50 +02:00
|
|
|
|
|
|
|
return rslot;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* ----------------------------------------------------------------
|
|
|
|
* ExecUpdate
|
|
|
|
*
|
|
|
|
* note: we can't run UPDATE queries with transactions
|
|
|
|
* off because UPDATEs are actually INSERTs and our
|
|
|
|
* scan will mistakenly loop forever, updating the tuple
|
2014-05-06 18:12:18 +02:00
|
|
|
* it just inserted.. This should be fixed but until it
|
2009-10-10 03:43:50 +02:00
|
|
|
* is, we don't want to get stuck in an infinite loop
|
|
|
|
* which corrupts your database..
|
|
|
|
*
|
2010-10-10 19:43:33 +02:00
|
|
|
* When updating a table, tupleid identifies the tuple to
|
|
|
|
* update and oldtuple is NULL. When updating a view, oldtuple
|
|
|
|
* is passed to the INSTEAD OF triggers and identifies what to
|
2013-03-10 19:14:53 +01:00
|
|
|
* update, and tupleid is invalid. When updating a foreign table,
|
2014-03-23 07:16:34 +01:00
|
|
|
* tupleid is invalid; the FDW has to figure out which row to
|
|
|
|
* update using data from the planSlot. oldtuple is passed to
|
|
|
|
* foreign table triggers; it is NULL when the foreign table has
|
|
|
|
* no relevant triggers.
|
2010-10-10 19:43:33 +02:00
|
|
|
*
|
2009-10-10 03:43:50 +02:00
|
|
|
* Returns RETURNING result if any, otherwise NULL.
|
|
|
|
* ----------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
static TupleTableSlot *
|
2017-06-28 19:55:03 +02:00
|
|
|
ExecUpdate(ModifyTableState *mtstate,
|
|
|
|
ItemPointer tupleid,
|
2014-03-23 07:16:34 +01:00
|
|
|
HeapTuple oldtuple,
|
2009-10-10 03:43:50 +02:00
|
|
|
TupleTableSlot *slot,
|
|
|
|
TupleTableSlot *planSlot,
|
Re-implement EvalPlanQual processing to improve its performance and eliminate
a lot of strange behaviors that occurred in join cases. We now identify the
"current" row for every joined relation in UPDATE, DELETE, and SELECT FOR
UPDATE/SHARE queries. If an EvalPlanQual recheck is necessary, we jam the
appropriate row into each scan node in the rechecking plan, forcing it to emit
only that one row. The former behavior could rescan the whole of each joined
relation for each recheck, which was terrible for performance, and what's much
worse could result in duplicated output tuples.
Also, the original implementation of EvalPlanQual could not re-use the recheck
execution tree --- it had to go through a full executor init and shutdown for
every row to be tested. To avoid this overhead, I've associated a special
runtime Param with each LockRows or ModifyTable plan node, and arranged to
make every scan node below such a node depend on that Param. Thus, by
signaling a change in that Param, the EPQ machinery can just rescan the
already-built test plan.
This patch also adds a prohibition on set-returning functions in the
targetlist of SELECT FOR UPDATE/SHARE. This is needed to avoid the
duplicate-output-tuple problem. It seems fairly reasonable since the
other restrictions on SELECT FOR UPDATE are meant to ensure that there
is a unique correspondence between source tuples and result tuples,
which an output SRF destroys as much as anything else does.
2009-10-26 03:26:45 +01:00
|
|
|
EPQState *epqstate,
|
2011-02-26 00:56:23 +01:00
|
|
|
EState *estate,
|
|
|
|
bool canSetTag)
|
2009-10-10 03:43:50 +02:00
|
|
|
{
|
|
|
|
HeapTuple tuple;
|
|
|
|
ResultRelInfo *resultRelInfo;
|
|
|
|
Relation resultRelationDesc;
|
|
|
|
HTSU_Result result;
|
2012-10-26 21:55:36 +02:00
|
|
|
HeapUpdateFailureData hufd;
|
2009-10-10 03:43:50 +02:00
|
|
|
List *recheckIndexes = NIL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* abort the operation if not running transactions
|
|
|
|
*/
|
|
|
|
if (IsBootstrapProcessingMode())
|
|
|
|
elog(ERROR, "cannot UPDATE during bootstrap");
|
|
|
|
|
|
|
|
/*
|
|
|
|
* get the heap tuple out of the tuple table slot, making sure we have a
|
|
|
|
* writable copy
|
|
|
|
*/
|
|
|
|
tuple = ExecMaterializeSlot(slot);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* get information on the (current) result relation
|
|
|
|
*/
|
|
|
|
resultRelInfo = estate->es_result_relation_info;
|
|
|
|
resultRelationDesc = resultRelInfo->ri_RelationDesc;
|
|
|
|
|
|
|
|
/* BEFORE ROW UPDATE Triggers */
|
|
|
|
if (resultRelInfo->ri_TrigDesc &&
|
2010-10-10 19:43:33 +02:00
|
|
|
resultRelInfo->ri_TrigDesc->trig_update_before_row)
|
2009-10-10 03:43:50 +02:00
|
|
|
{
|
2011-02-22 03:18:04 +01:00
|
|
|
slot = ExecBRUpdateTriggers(estate, epqstate, resultRelInfo,
|
2014-03-23 07:16:34 +01:00
|
|
|
tupleid, oldtuple, slot);
|
2009-10-10 03:43:50 +02:00
|
|
|
|
2011-02-22 03:18:04 +01:00
|
|
|
if (slot == NULL) /* "do nothing" */
|
2009-10-10 03:43:50 +02:00
|
|
|
return NULL;
|
|
|
|
|
2011-02-22 03:18:04 +01:00
|
|
|
/* trigger might have changed tuple */
|
|
|
|
tuple = ExecMaterializeSlot(slot);
|
2009-10-10 03:43:50 +02:00
|
|
|
}
|
|
|
|
|
2010-10-10 19:43:33 +02:00
|
|
|
/* INSTEAD OF ROW UPDATE Triggers */
|
|
|
|
if (resultRelInfo->ri_TrigDesc &&
|
|
|
|
resultRelInfo->ri_TrigDesc->trig_update_instead_row)
|
2009-10-10 03:43:50 +02:00
|
|
|
{
|
2011-02-22 03:18:04 +01:00
|
|
|
slot = ExecIRUpdateTriggers(estate, resultRelInfo,
|
2014-03-23 07:16:34 +01:00
|
|
|
oldtuple, slot);
|
2010-10-10 19:43:33 +02:00
|
|
|
|
2011-02-22 03:18:04 +01:00
|
|
|
if (slot == NULL) /* "do nothing" */
|
2009-10-10 03:43:50 +02:00
|
|
|
return NULL;
|
|
|
|
|
2011-02-22 03:18:04 +01:00
|
|
|
/* trigger might have changed tuple */
|
|
|
|
tuple = ExecMaterializeSlot(slot);
|
2010-10-10 19:43:33 +02:00
|
|
|
}
|
2013-03-10 19:14:53 +01:00
|
|
|
else if (resultRelInfo->ri_FdwRoutine)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* update in foreign table: let the FDW do it
|
|
|
|
*/
|
|
|
|
slot = resultRelInfo->ri_FdwRoutine->ExecForeignUpdate(estate,
|
|
|
|
resultRelInfo,
|
|
|
|
slot,
|
|
|
|
planSlot);
|
|
|
|
|
|
|
|
if (slot == NULL) /* "do nothing" */
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
/* FDW might have changed tuple */
|
|
|
|
tuple = ExecMaterializeSlot(slot);
|
2016-02-05 03:15:57 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* AFTER ROW Triggers or RETURNING expressions might reference the
|
|
|
|
* tableoid column, so initialize t_tableOid before evaluating them.
|
|
|
|
*/
|
|
|
|
tuple->t_tableOid = RelationGetRelid(resultRelationDesc);
|
2013-03-10 19:14:53 +01:00
|
|
|
}
|
2010-10-10 19:43:33 +02:00
|
|
|
else
|
|
|
|
{
|
2013-05-29 22:58:43 +02:00
|
|
|
LockTupleMode lockmode;
|
Improve concurrency of foreign key locking
This patch introduces two additional lock modes for tuples: "SELECT FOR
KEY SHARE" and "SELECT FOR NO KEY UPDATE". These don't block each
other, in contrast with already existing "SELECT FOR SHARE" and "SELECT
FOR UPDATE". UPDATE commands that do not modify the values stored in
the columns that are part of the key of the tuple now grab a SELECT FOR
NO KEY UPDATE lock on the tuple, allowing them to proceed concurrently
with tuple locks of the FOR KEY SHARE variety.
Foreign key triggers now use FOR KEY SHARE instead of FOR SHARE; this
means the concurrency improvement applies to them, which is the whole
point of this patch.
The added tuple lock semantics require some rejiggering of the multixact
module, so that the locking level that each transaction is holding can
be stored alongside its Xid. Also, multixacts now need to persist
across server restarts and crashes, because they can now represent not
only tuple locks, but also tuple updates. This means we need more
careful tracking of lifetime of pg_multixact SLRU files; since they now
persist longer, we require more infrastructure to figure out when they
can be removed. pg_upgrade also needs to be careful to copy
pg_multixact files over from the old server to the new, or at least part
of multixact.c state, depending on the versions of the old and new
servers.
Tuple time qualification rules (HeapTupleSatisfies routines) need to be
careful not to consider tuples with the "is multi" infomask bit set as
being only locked; they might need to look up MultiXact values (i.e.
possibly do pg_multixact I/O) to find out the Xid that updated a tuple,
whereas they previously were assured to only use information readily
available from the tuple header. This is considered acceptable, because
the extra I/O would involve cases that would previously cause some
commands to block waiting for concurrent transactions to finish.
Another important change is the fact that locking tuples that have
previously been updated causes the future versions to be marked as
locked, too; this is essential for correctness of foreign key checks.
This causes additional WAL-logging, also (there was previously a single
WAL record for a locked tuple; now there are as many as updated copies
of the tuple there exist.)
With all this in place, contention related to tuples being checked by
foreign key rules should be much reduced.
As a bonus, the old behavior that a subtransaction grabbing a stronger
tuple lock than the parent (sub)transaction held on a given tuple and
later aborting caused the weaker lock to be lost, has been fixed.
Many new spec files were added for isolation tester framework, to ensure
overall behavior is sane. There's probably room for several more tests.
There were several reviewers of this patch; in particular, Noah Misch
and Andres Freund spent considerable time in it. Original idea for the
patch came from Simon Riggs, after a problem report by Joel Jacobson.
Most code is from me, with contributions from Marti Raudsepp, Alexander
Shulgin, Noah Misch and Andres Freund.
This patch was discussed in several pgsql-hackers threads; the most
important start at the following message-ids:
AANLkTimo9XVcEzfiBR-ut3KVNDkjm2Vxh+t8kAmWjPuv@mail.gmail.com
1290721684-sup-3951@alvh.no-ip.org
1294953201-sup-2099@alvh.no-ip.org
1320343602-sup-2290@alvh.no-ip.org
1339690386-sup-8927@alvh.no-ip.org
4FE5FF020200002500048A3D@gw.wicourts.gov
4FEAB90A0200002500048B7D@gw.wicourts.gov
2013-01-23 16:04:59 +01:00
|
|
|
|
Don't allow system columns in CHECK constraints, except tableoid.
Previously, arbitray system columns could be mentioned in table
constraints, but they were not correctly checked at runtime, because
the values weren't actually set correctly in the tuple. Since it
seems easy enough to initialize the table OID properly, do that,
and continue allowing that column, but disallow the rest unless and
until someone figures out a way to make them work properly.
No back-patch, because this doesn't seem important enough to take the
risk of destabilizing the back branches. In fact, this will pose a
dump-and-reload hazard for those upgrading from previous versions:
constraints that were accepted before but were not correctly enforced
will now either be enforced correctly or not accepted at all. Either
could result in restore failures, but in practice I think very few
users will notice the difference, since the use case is pretty
marginal anyway and few users will be relying on features that have
not historically worked.
Amit Kapila, reviewed by Rushabh Lathia, with doc changes by me.
2013-09-23 19:31:22 +02:00
|
|
|
/*
|
|
|
|
* Constraints might reference the tableoid column, so initialize
|
|
|
|
* t_tableOid before evaluating them.
|
|
|
|
*/
|
|
|
|
tuple->t_tableOid = RelationGetRelid(resultRelationDesc);
|
|
|
|
|
2010-10-10 19:43:33 +02:00
|
|
|
/*
|
2015-04-25 02:34:26 +02:00
|
|
|
* Check any RLS UPDATE WITH CHECK policies
|
2010-10-10 19:43:33 +02:00
|
|
|
*
|
|
|
|
* If we generate a new candidate tuple after EvalPlanQual testing, we
|
2015-04-25 02:34:26 +02:00
|
|
|
* must loop back here and recheck any RLS policies and constraints.
|
|
|
|
* (We don't need to redo triggers, however. If there are any BEFORE
|
|
|
|
* triggers then trigger.c will have done heap_lock_tuple to lock the
|
|
|
|
* correct tuple, so there's no need to do them again.)
|
|
|
|
*
|
2015-05-24 03:35:49 +02:00
|
|
|
* ExecWithCheckOptions() will skip any WCOs which are not of the kind
|
|
|
|
* we are looking for at this point.
|
2010-10-10 19:43:33 +02:00
|
|
|
*/
|
|
|
|
lreplace:;
|
2015-04-25 02:34:26 +02:00
|
|
|
if (resultRelInfo->ri_WithCheckOptions != NIL)
|
|
|
|
ExecWithCheckOptions(WCO_RLS_UPDATE_CHECK,
|
|
|
|
resultRelInfo, slot, estate);
|
|
|
|
|
|
|
|
/*
|
2017-01-04 20:36:34 +01:00
|
|
|
* Check the constraints of the tuple. Note that we pass the same
|
|
|
|
* slot for the orig_slot argument, because unlike ExecInsert(), no
|
|
|
|
* tuple-routing is performed here, hence the slot remains unchanged.
|
2015-04-25 02:34:26 +02:00
|
|
|
*/
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
if (resultRelationDesc->rd_att->constr || resultRelInfo->ri_PartitionCheck)
|
2017-04-10 18:20:08 +02:00
|
|
|
ExecConstraints(resultRelInfo, slot, estate);
|
2010-10-10 19:43:33 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* replace the heap tuple
|
|
|
|
*
|
|
|
|
* Note: if es_crosscheck_snapshot isn't InvalidSnapshot, we check
|
|
|
|
* that the row to be updated is visible to that snapshot, and throw a
|
|
|
|
* can't-serialize error if not. This is a special-case behavior
|
|
|
|
* needed for referential integrity updates in transaction-snapshot
|
|
|
|
* mode transactions.
|
|
|
|
*/
|
|
|
|
result = heap_update(resultRelationDesc, tupleid, tuple,
|
|
|
|
estate->es_output_cid,
|
|
|
|
estate->es_crosscheck_snapshot,
|
2013-05-29 22:58:43 +02:00
|
|
|
true /* wait for commit */ ,
|
Improve concurrency of foreign key locking
This patch introduces two additional lock modes for tuples: "SELECT FOR
KEY SHARE" and "SELECT FOR NO KEY UPDATE". These don't block each
other, in contrast with already existing "SELECT FOR SHARE" and "SELECT
FOR UPDATE". UPDATE commands that do not modify the values stored in
the columns that are part of the key of the tuple now grab a SELECT FOR
NO KEY UPDATE lock on the tuple, allowing them to proceed concurrently
with tuple locks of the FOR KEY SHARE variety.
Foreign key triggers now use FOR KEY SHARE instead of FOR SHARE; this
means the concurrency improvement applies to them, which is the whole
point of this patch.
The added tuple lock semantics require some rejiggering of the multixact
module, so that the locking level that each transaction is holding can
be stored alongside its Xid. Also, multixacts now need to persist
across server restarts and crashes, because they can now represent not
only tuple locks, but also tuple updates. This means we need more
careful tracking of lifetime of pg_multixact SLRU files; since they now
persist longer, we require more infrastructure to figure out when they
can be removed. pg_upgrade also needs to be careful to copy
pg_multixact files over from the old server to the new, or at least part
of multixact.c state, depending on the versions of the old and new
servers.
Tuple time qualification rules (HeapTupleSatisfies routines) need to be
careful not to consider tuples with the "is multi" infomask bit set as
being only locked; they might need to look up MultiXact values (i.e.
possibly do pg_multixact I/O) to find out the Xid that updated a tuple,
whereas they previously were assured to only use information readily
available from the tuple header. This is considered acceptable, because
the extra I/O would involve cases that would previously cause some
commands to block waiting for concurrent transactions to finish.
Another important change is the fact that locking tuples that have
previously been updated causes the future versions to be marked as
locked, too; this is essential for correctness of foreign key checks.
This causes additional WAL-logging, also (there was previously a single
WAL record for a locked tuple; now there are as many as updated copies
of the tuple there exist.)
With all this in place, contention related to tuples being checked by
foreign key rules should be much reduced.
As a bonus, the old behavior that a subtransaction grabbing a stronger
tuple lock than the parent (sub)transaction held on a given tuple and
later aborting caused the weaker lock to be lost, has been fixed.
Many new spec files were added for isolation tester framework, to ensure
overall behavior is sane. There's probably room for several more tests.
There were several reviewers of this patch; in particular, Noah Misch
and Andres Freund spent considerable time in it. Original idea for the
patch came from Simon Riggs, after a problem report by Joel Jacobson.
Most code is from me, with contributions from Marti Raudsepp, Alexander
Shulgin, Noah Misch and Andres Freund.
This patch was discussed in several pgsql-hackers threads; the most
important start at the following message-ids:
AANLkTimo9XVcEzfiBR-ut3KVNDkjm2Vxh+t8kAmWjPuv@mail.gmail.com
1290721684-sup-3951@alvh.no-ip.org
1294953201-sup-2099@alvh.no-ip.org
1320343602-sup-2290@alvh.no-ip.org
1339690386-sup-8927@alvh.no-ip.org
4FE5FF020200002500048A3D@gw.wicourts.gov
4FEAB90A0200002500048B7D@gw.wicourts.gov
2013-01-23 16:04:59 +01:00
|
|
|
&hufd, &lockmode);
|
2010-10-10 19:43:33 +02:00
|
|
|
switch (result)
|
|
|
|
{
|
|
|
|
case HeapTupleSelfUpdated:
|
2013-05-29 22:58:43 +02:00
|
|
|
|
2012-10-26 21:55:36 +02:00
|
|
|
/*
|
|
|
|
* The target tuple was already updated or deleted by the
|
|
|
|
* current command, or by a later command in the current
|
|
|
|
* transaction. The former case is possible in a join UPDATE
|
2013-05-29 22:58:43 +02:00
|
|
|
* where multiple tuples join to the same target tuple. This
|
|
|
|
* is pretty questionable, but Postgres has always allowed it:
|
|
|
|
* we just execute the first update action and ignore
|
|
|
|
* additional update attempts.
|
2012-10-26 21:55:36 +02:00
|
|
|
*
|
|
|
|
* The latter case arises if the tuple is modified by a
|
|
|
|
* command in a BEFORE trigger, or perhaps by a command in a
|
|
|
|
* volatile function used in the query. In such situations we
|
|
|
|
* should not ignore the update, but it is equally unsafe to
|
|
|
|
* proceed. We don't want to discard the original UPDATE
|
|
|
|
* while keeping the triggered actions based on it; and we
|
|
|
|
* have no principled way to merge this update with the
|
|
|
|
* previous ones. So throwing an error is the only safe
|
|
|
|
* course.
|
|
|
|
*
|
2013-05-29 22:58:43 +02:00
|
|
|
* If a trigger actually intends this type of interaction, it
|
|
|
|
* can re-execute the UPDATE (assuming it can figure out how)
|
|
|
|
* and then return NULL to cancel the outer update.
|
2012-10-26 21:55:36 +02:00
|
|
|
*/
|
|
|
|
if (hufd.cmax != estate->es_output_cid)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_TRIGGERED_DATA_CHANGE_VIOLATION),
|
|
|
|
errmsg("tuple to be updated was already modified by an operation triggered by the current command"),
|
|
|
|
errhint("Consider using an AFTER trigger instead of a BEFORE trigger to propagate changes to other rows.")));
|
|
|
|
|
|
|
|
/* Else, already updated by self; nothing to do */
|
2010-10-10 19:43:33 +02:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
case HeapTupleMayBeUpdated:
|
|
|
|
break;
|
|
|
|
|
|
|
|
case HeapTupleUpdated:
|
|
|
|
if (IsolationUsesXactSnapshot())
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_T_R_SERIALIZATION_FAILURE),
|
|
|
|
errmsg("could not serialize access due to concurrent update")));
|
2012-10-26 21:55:36 +02:00
|
|
|
if (!ItemPointerEquals(tupleid, &hufd.ctid))
|
2009-10-10 03:43:50 +02:00
|
|
|
{
|
2010-10-10 19:43:33 +02:00
|
|
|
TupleTableSlot *epqslot;
|
|
|
|
|
|
|
|
epqslot = EvalPlanQual(estate,
|
|
|
|
epqstate,
|
|
|
|
resultRelationDesc,
|
|
|
|
resultRelInfo->ri_RangeTableIndex,
|
Improve concurrency of foreign key locking
This patch introduces two additional lock modes for tuples: "SELECT FOR
KEY SHARE" and "SELECT FOR NO KEY UPDATE". These don't block each
other, in contrast with already existing "SELECT FOR SHARE" and "SELECT
FOR UPDATE". UPDATE commands that do not modify the values stored in
the columns that are part of the key of the tuple now grab a SELECT FOR
NO KEY UPDATE lock on the tuple, allowing them to proceed concurrently
with tuple locks of the FOR KEY SHARE variety.
Foreign key triggers now use FOR KEY SHARE instead of FOR SHARE; this
means the concurrency improvement applies to them, which is the whole
point of this patch.
The added tuple lock semantics require some rejiggering of the multixact
module, so that the locking level that each transaction is holding can
be stored alongside its Xid. Also, multixacts now need to persist
across server restarts and crashes, because they can now represent not
only tuple locks, but also tuple updates. This means we need more
careful tracking of lifetime of pg_multixact SLRU files; since they now
persist longer, we require more infrastructure to figure out when they
can be removed. pg_upgrade also needs to be careful to copy
pg_multixact files over from the old server to the new, or at least part
of multixact.c state, depending on the versions of the old and new
servers.
Tuple time qualification rules (HeapTupleSatisfies routines) need to be
careful not to consider tuples with the "is multi" infomask bit set as
being only locked; they might need to look up MultiXact values (i.e.
possibly do pg_multixact I/O) to find out the Xid that updated a tuple,
whereas they previously were assured to only use information readily
available from the tuple header. This is considered acceptable, because
the extra I/O would involve cases that would previously cause some
commands to block waiting for concurrent transactions to finish.
Another important change is the fact that locking tuples that have
previously been updated causes the future versions to be marked as
locked, too; this is essential for correctness of foreign key checks.
This causes additional WAL-logging, also (there was previously a single
WAL record for a locked tuple; now there are as many as updated copies
of the tuple there exist.)
With all this in place, contention related to tuples being checked by
foreign key rules should be much reduced.
As a bonus, the old behavior that a subtransaction grabbing a stronger
tuple lock than the parent (sub)transaction held on a given tuple and
later aborting caused the weaker lock to be lost, has been fixed.
Many new spec files were added for isolation tester framework, to ensure
overall behavior is sane. There's probably room for several more tests.
There were several reviewers of this patch; in particular, Noah Misch
and Andres Freund spent considerable time in it. Original idea for the
patch came from Simon Riggs, after a problem report by Joel Jacobson.
Most code is from me, with contributions from Marti Raudsepp, Alexander
Shulgin, Noah Misch and Andres Freund.
This patch was discussed in several pgsql-hackers threads; the most
important start at the following message-ids:
AANLkTimo9XVcEzfiBR-ut3KVNDkjm2Vxh+t8kAmWjPuv@mail.gmail.com
1290721684-sup-3951@alvh.no-ip.org
1294953201-sup-2099@alvh.no-ip.org
1320343602-sup-2290@alvh.no-ip.org
1339690386-sup-8927@alvh.no-ip.org
4FE5FF020200002500048A3D@gw.wicourts.gov
4FEAB90A0200002500048B7D@gw.wicourts.gov
2013-01-23 16:04:59 +01:00
|
|
|
lockmode,
|
2012-10-26 21:55:36 +02:00
|
|
|
&hufd.ctid,
|
|
|
|
hufd.xmax);
|
2010-10-10 19:43:33 +02:00
|
|
|
if (!TupIsNull(epqslot))
|
|
|
|
{
|
2012-10-26 21:55:36 +02:00
|
|
|
*tupleid = hufd.ctid;
|
2010-10-10 19:43:33 +02:00
|
|
|
slot = ExecFilterJunk(resultRelInfo->ri_junkFilter, epqslot);
|
|
|
|
tuple = ExecMaterializeSlot(slot);
|
|
|
|
goto lreplace;
|
|
|
|
}
|
2009-10-10 03:43:50 +02:00
|
|
|
}
|
2010-10-10 19:43:33 +02:00
|
|
|
/* tuple already deleted; nothing to do */
|
|
|
|
return NULL;
|
2009-10-10 03:43:50 +02:00
|
|
|
|
2010-10-10 19:43:33 +02:00
|
|
|
default:
|
|
|
|
elog(ERROR, "unrecognized heap_update status: %u", result);
|
|
|
|
return NULL;
|
|
|
|
}
|
2009-10-10 03:43:50 +02:00
|
|
|
|
2010-10-10 19:43:33 +02:00
|
|
|
/*
|
|
|
|
* Note: instead of having to update the old index tuples associated
|
2011-04-10 17:42:00 +02:00
|
|
|
* with the heap tuple, all we do is form and insert new index tuples.
|
|
|
|
* This is because UPDATEs are actually DELETEs and INSERTs, and index
|
|
|
|
* tuple deletion is done later by VACUUM (see notes in ExecDelete).
|
|
|
|
* All we do here is insert new index tuples. -cim 9/27/89
|
2010-10-10 19:43:33 +02:00
|
|
|
*/
|
2009-10-10 03:43:50 +02:00
|
|
|
|
2010-10-10 19:43:33 +02:00
|
|
|
/*
|
|
|
|
* insert index entries for tuple
|
|
|
|
*
|
|
|
|
* Note: heap_update returns the tid (location) of the new tuple in
|
|
|
|
* the t_self field.
|
|
|
|
*
|
|
|
|
* If it's a HOT update, we mustn't insert new index entries.
|
|
|
|
*/
|
|
|
|
if (resultRelInfo->ri_NumIndices > 0 && !HeapTupleIsHeapOnly(tuple))
|
|
|
|
recheckIndexes = ExecInsertIndexTuples(slot, &(tuple->t_self),
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
estate, false, NULL, NIL);
|
2010-10-10 19:43:33 +02:00
|
|
|
}
|
2009-10-10 03:43:50 +02:00
|
|
|
|
2011-02-26 00:56:23 +01:00
|
|
|
if (canSetTag)
|
|
|
|
(estate->es_processed)++;
|
2009-10-10 03:43:50 +02:00
|
|
|
|
|
|
|
/* AFTER ROW UPDATE Triggers */
|
2014-03-23 07:16:34 +01:00
|
|
|
ExecARUpdateTriggers(estate, resultRelInfo, tupleid, oldtuple, tuple,
|
2017-06-28 19:55:03 +02:00
|
|
|
recheckIndexes,
|
|
|
|
mtstate->mt_transition_capture);
|
2010-01-31 19:15:39 +01:00
|
|
|
|
|
|
|
list_free(recheckIndexes);
|
2009-10-10 03:43:50 +02:00
|
|
|
|
2015-04-25 02:34:26 +02:00
|
|
|
/*
|
2015-05-24 03:35:49 +02:00
|
|
|
* Check any WITH CHECK OPTION constraints from parent views. We are
|
|
|
|
* required to do this after testing all constraints and uniqueness
|
|
|
|
* violations per the SQL spec, so we do it after actually updating the
|
|
|
|
* record in the heap and all indexes.
|
2015-04-25 02:34:26 +02:00
|
|
|
*
|
2015-05-24 03:35:49 +02:00
|
|
|
* ExecWithCheckOptions() will skip any WCOs which are not of the kind we
|
|
|
|
* are looking for at this point.
|
2015-04-25 02:34:26 +02:00
|
|
|
*/
|
2013-07-18 23:10:16 +02:00
|
|
|
if (resultRelInfo->ri_WithCheckOptions != NIL)
|
2015-04-25 02:34:26 +02:00
|
|
|
ExecWithCheckOptions(WCO_VIEW_CHECK, resultRelInfo, slot, estate);
|
2013-07-18 23:10:16 +02:00
|
|
|
|
2009-10-10 03:43:50 +02:00
|
|
|
/* Process RETURNING if present */
|
|
|
|
if (resultRelInfo->ri_projectReturning)
|
2016-03-18 18:48:58 +01:00
|
|
|
return ExecProcessReturning(resultRelInfo, slot, planSlot);
|
2009-10-10 03:43:50 +02:00
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
/*
|
|
|
|
* ExecOnConflictUpdate --- execute UPDATE of INSERT ON CONFLICT DO UPDATE
|
|
|
|
*
|
|
|
|
* Try to lock tuple for update as part of speculative insertion. If
|
|
|
|
* a qual originating from ON CONFLICT DO UPDATE is satisfied, update
|
|
|
|
* (but still lock row, even though it may not satisfy estate's
|
|
|
|
* snapshot).
|
|
|
|
*
|
|
|
|
* Returns true if if we're done (with or without an update), or false if
|
|
|
|
* the caller must retry the INSERT from scratch.
|
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
ExecOnConflictUpdate(ModifyTableState *mtstate,
|
|
|
|
ResultRelInfo *resultRelInfo,
|
|
|
|
ItemPointer conflictTid,
|
|
|
|
TupleTableSlot *planSlot,
|
|
|
|
TupleTableSlot *excludedSlot,
|
|
|
|
EState *estate,
|
|
|
|
bool canSetTag,
|
|
|
|
TupleTableSlot **returning)
|
|
|
|
{
|
|
|
|
ExprContext *econtext = mtstate->ps.ps_ExprContext;
|
|
|
|
Relation relation = resultRelInfo->ri_RelationDesc;
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
ExprState *onConflictSetWhere = resultRelInfo->ri_onConflictSetWhere;
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
HeapTupleData tuple;
|
|
|
|
HeapUpdateFailureData hufd;
|
|
|
|
LockTupleMode lockmode;
|
|
|
|
HTSU_Result test;
|
|
|
|
Buffer buffer;
|
|
|
|
|
|
|
|
/* Determine lock mode to use */
|
|
|
|
lockmode = ExecUpdateLockMode(estate, resultRelInfo);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Lock tuple for update. Don't follow updates when tuple cannot be
|
|
|
|
* locked without doing so. A row locking conflict here means our
|
|
|
|
* previous conclusion that the tuple is conclusively committed is not
|
|
|
|
* true anymore.
|
|
|
|
*/
|
|
|
|
tuple.t_self = *conflictTid;
|
|
|
|
test = heap_lock_tuple(relation, &tuple, estate->es_output_cid,
|
|
|
|
lockmode, LockWaitBlock, false, &buffer,
|
|
|
|
&hufd);
|
|
|
|
switch (test)
|
|
|
|
{
|
|
|
|
case HeapTupleMayBeUpdated:
|
|
|
|
/* success! */
|
|
|
|
break;
|
|
|
|
|
|
|
|
case HeapTupleInvisible:
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This can occur when a just inserted tuple is updated again in
|
|
|
|
* the same command. E.g. because multiple rows with the same
|
|
|
|
* conflicting key values are inserted.
|
|
|
|
*
|
|
|
|
* This is somewhat similar to the ExecUpdate()
|
|
|
|
* HeapTupleSelfUpdated case. We do not want to proceed because
|
|
|
|
* it would lead to the same row being updated a second time in
|
|
|
|
* some unspecified order, and in contrast to plain UPDATEs
|
|
|
|
* there's no historical behavior to break.
|
|
|
|
*
|
|
|
|
* It is the user's responsibility to prevent this situation from
|
|
|
|
* occurring. These problems are why SQL-2003 similarly specifies
|
|
|
|
* that for SQL MERGE, an exception must be raised in the event of
|
|
|
|
* an attempt to update the same row twice.
|
|
|
|
*/
|
|
|
|
if (TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetXmin(tuple.t_data)))
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_CARDINALITY_VIOLATION),
|
|
|
|
errmsg("ON CONFLICT DO UPDATE command cannot affect row a second time"),
|
|
|
|
errhint("Ensure that no rows proposed for insertion within the same command have duplicate constrained values.")));
|
|
|
|
|
|
|
|
/* This shouldn't happen */
|
|
|
|
elog(ERROR, "attempted to lock invisible tuple");
|
|
|
|
|
|
|
|
case HeapTupleSelfUpdated:
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This state should never be reached. As a dirty snapshot is used
|
|
|
|
* to find conflicting tuples, speculative insertion wouldn't have
|
|
|
|
* seen this row to conflict with.
|
|
|
|
*/
|
|
|
|
elog(ERROR, "unexpected self-updated tuple");
|
|
|
|
|
|
|
|
case HeapTupleUpdated:
|
|
|
|
if (IsolationUsesXactSnapshot())
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_T_R_SERIALIZATION_FAILURE),
|
|
|
|
errmsg("could not serialize access due to concurrent update")));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Tell caller to try again from the very start.
|
|
|
|
*
|
|
|
|
* It does not make sense to use the usual EvalPlanQual() style
|
|
|
|
* loop here, as the new version of the row might not conflict
|
|
|
|
* anymore, or the conflicting tuple has actually been deleted.
|
|
|
|
*/
|
|
|
|
ReleaseBuffer(buffer);
|
|
|
|
return false;
|
|
|
|
|
|
|
|
default:
|
|
|
|
elog(ERROR, "unrecognized heap_lock_tuple status: %u", test);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Success, the tuple is locked.
|
|
|
|
*
|
|
|
|
* Reset per-tuple memory context to free any expression evaluation
|
|
|
|
* storage allocated in the previous cycle.
|
|
|
|
*/
|
|
|
|
ResetExprContext(econtext);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Verify that the tuple is visible to our MVCC snapshot if the current
|
|
|
|
* isolation level mandates that.
|
|
|
|
*
|
|
|
|
* It's not sufficient to rely on the check within ExecUpdate() as e.g.
|
|
|
|
* CONFLICT ... WHERE clause may prevent us from reaching that.
|
|
|
|
*
|
|
|
|
* This means we only ever continue when a new command in the current
|
|
|
|
* transaction could see the row, even though in READ COMMITTED mode the
|
|
|
|
* tuple will not be visible according to the current statement's
|
|
|
|
* snapshot. This is in line with the way UPDATE deals with newer tuple
|
|
|
|
* versions.
|
|
|
|
*/
|
|
|
|
ExecCheckHeapTupleVisible(estate, &tuple, buffer);
|
|
|
|
|
|
|
|
/* Store target's existing tuple in the state's dedicated slot */
|
|
|
|
ExecStoreTuple(&tuple, mtstate->mt_existing, buffer, false);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Make tuple and any needed join variables available to ExecQual and
|
|
|
|
* ExecProject. The EXCLUDED tuple is installed in ecxt_innertuple, while
|
2015-05-24 03:35:49 +02:00
|
|
|
* the target's existing tuple is installed in the scantuple. EXCLUDED
|
|
|
|
* has been made to reference INNER_VAR in setrefs.c, but there is no
|
|
|
|
* other redirection.
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
*/
|
|
|
|
econtext->ecxt_scantuple = mtstate->mt_existing;
|
|
|
|
econtext->ecxt_innertuple = excludedSlot;
|
|
|
|
econtext->ecxt_outertuple = NULL;
|
|
|
|
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
if (!ExecQual(onConflictSetWhere, econtext))
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
{
|
|
|
|
ReleaseBuffer(buffer);
|
|
|
|
InstrCountFiltered1(&mtstate->ps, 1);
|
|
|
|
return true; /* done with the tuple */
|
|
|
|
}
|
|
|
|
|
|
|
|
if (resultRelInfo->ri_WithCheckOptions != NIL)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Check target's existing tuple against UPDATE-applicable USING
|
|
|
|
* security barrier quals (if any), enforced here as RLS checks/WCOs.
|
|
|
|
*
|
|
|
|
* The rewriter creates UPDATE RLS checks/WCOs for UPDATE security
|
|
|
|
* quals, and stores them as WCOs of "kind" WCO_RLS_CONFLICT_CHECK,
|
|
|
|
* but that's almost the extent of its special handling for ON
|
|
|
|
* CONFLICT DO UPDATE.
|
|
|
|
*
|
|
|
|
* The rewriter will also have associated UPDATE applicable straight
|
|
|
|
* RLS checks/WCOs for the benefit of the ExecUpdate() call that
|
|
|
|
* follows. INSERTs and UPDATEs naturally have mutually exclusive WCO
|
|
|
|
* kinds, so there is no danger of spurious over-enforcement in the
|
|
|
|
* INSERT or UPDATE path.
|
|
|
|
*/
|
|
|
|
ExecWithCheckOptions(WCO_RLS_CONFLICT_CHECK, resultRelInfo,
|
|
|
|
mtstate->mt_existing,
|
|
|
|
mtstate->ps.state);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Project the new tuple version */
|
2017-01-19 23:12:38 +01:00
|
|
|
ExecProject(resultRelInfo->ri_onConflictSetProj);
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
|
Fix ON CONFLICT UPDATE bug breaking AFTER UPDATE triggers.
ExecOnConflictUpdate() passed t_ctid of the to-be-updated tuple to
ExecUpdate(). That's problematic primarily because of two reason: First
and foremost t_ctid could point to a different tuple. Secondly, and
that's what triggered the complaint by Stanislav, t_ctid is changed by
heap_update() to point to the new tuple version. The behavior of AFTER
UPDATE triggers was therefore broken, with NEW.* and OLD.* tuples
spuriously identical within AFTER UPDATE triggers.
To fix both issues, pass a pointer to t_self of a on-stack HeapTuple
instead.
Fixing this bug lead to one change in regression tests, which previously
failed due to the first issue mentioned above. There's a reasonable
expectation that test fails, as it updates one row repeatedly within one
INSERT ... ON CONFLICT statement. That is only possible if the second
update is triggered via ON CONFLICT ... SET, ON CONFLICT ... WHERE, or
by a WITH CHECK expression, as those are executed after
ExecOnConflictUpdate() does a visibility check. That could easily be
prohibited, but given it's allowed for plain UPDATEs and a rare corner
case, it doesn't seem worthwhile.
Reported-By: Stanislav Grozev
Author: Andres Freund and Peter Geoghegan
Discussion: CAA78GVqy1+LisN-8DygekD_Ldfy=BJLarSpjGhytOsgkpMavfQ@mail.gmail.com
Backpatch: 9.5, where ON CONFLICT was introduced
2015-12-10 16:26:45 +01:00
|
|
|
/*
|
|
|
|
* Note that it is possible that the target tuple has been modified in
|
|
|
|
* this session, after the above heap_lock_tuple. We choose to not error
|
2016-06-10 00:02:36 +02:00
|
|
|
* out in that case, in line with ExecUpdate's treatment of similar cases.
|
|
|
|
* This can happen if an UPDATE is triggered from within ExecQual(),
|
|
|
|
* ExecWithCheckOptions() or ExecProject() above, e.g. by selecting from a
|
|
|
|
* wCTE in the ON CONFLICT's SET.
|
Fix ON CONFLICT UPDATE bug breaking AFTER UPDATE triggers.
ExecOnConflictUpdate() passed t_ctid of the to-be-updated tuple to
ExecUpdate(). That's problematic primarily because of two reason: First
and foremost t_ctid could point to a different tuple. Secondly, and
that's what triggered the complaint by Stanislav, t_ctid is changed by
heap_update() to point to the new tuple version. The behavior of AFTER
UPDATE triggers was therefore broken, with NEW.* and OLD.* tuples
spuriously identical within AFTER UPDATE triggers.
To fix both issues, pass a pointer to t_self of a on-stack HeapTuple
instead.
Fixing this bug lead to one change in regression tests, which previously
failed due to the first issue mentioned above. There's a reasonable
expectation that test fails, as it updates one row repeatedly within one
INSERT ... ON CONFLICT statement. That is only possible if the second
update is triggered via ON CONFLICT ... SET, ON CONFLICT ... WHERE, or
by a WITH CHECK expression, as those are executed after
ExecOnConflictUpdate() does a visibility check. That could easily be
prohibited, but given it's allowed for plain UPDATEs and a rare corner
case, it doesn't seem worthwhile.
Reported-By: Stanislav Grozev
Author: Andres Freund and Peter Geoghegan
Discussion: CAA78GVqy1+LisN-8DygekD_Ldfy=BJLarSpjGhytOsgkpMavfQ@mail.gmail.com
Backpatch: 9.5, where ON CONFLICT was introduced
2015-12-10 16:26:45 +01:00
|
|
|
*/
|
|
|
|
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
/* Execute UPDATE with projection */
|
2017-06-28 19:55:03 +02:00
|
|
|
*returning = ExecUpdate(mtstate, &tuple.t_self, NULL,
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
mtstate->mt_conflproj, planSlot,
|
|
|
|
&mtstate->mt_epqstate, mtstate->ps.state,
|
|
|
|
canSetTag);
|
|
|
|
|
|
|
|
ReleaseBuffer(buffer);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2009-10-10 03:43:50 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Process BEFORE EACH STATEMENT triggers
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
fireBSTriggers(ModifyTableState *node)
|
|
|
|
{
|
2017-05-17 22:31:56 +02:00
|
|
|
ResultRelInfo *resultRelInfo = node->resultRelInfo;
|
2017-05-01 14:23:01 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If the node modifies a partitioned table, we must fire its triggers.
|
|
|
|
* Note that in that case, node->resultRelInfo points to the first leaf
|
|
|
|
* partition, not the root table.
|
|
|
|
*/
|
|
|
|
if (node->rootResultRelInfo != NULL)
|
|
|
|
resultRelInfo = node->rootResultRelInfo;
|
|
|
|
|
2009-10-10 03:43:50 +02:00
|
|
|
switch (node->operation)
|
|
|
|
{
|
|
|
|
case CMD_INSERT:
|
2017-05-01 14:23:01 +02:00
|
|
|
ExecBSInsertTriggers(node->ps.state, resultRelInfo);
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
if (node->mt_onconflict == ONCONFLICT_UPDATE)
|
|
|
|
ExecBSUpdateTriggers(node->ps.state,
|
2017-05-01 14:23:01 +02:00
|
|
|
resultRelInfo);
|
2009-10-10 03:43:50 +02:00
|
|
|
break;
|
|
|
|
case CMD_UPDATE:
|
2017-05-01 14:23:01 +02:00
|
|
|
ExecBSUpdateTriggers(node->ps.state, resultRelInfo);
|
2009-10-10 03:43:50 +02:00
|
|
|
break;
|
|
|
|
case CMD_DELETE:
|
2017-05-01 14:23:01 +02:00
|
|
|
ExecBSDeleteTriggers(node->ps.state, resultRelInfo);
|
2009-10-10 03:43:50 +02:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
elog(ERROR, "unknown operation");
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2017-06-28 19:55:03 +02:00
|
|
|
* Return the ResultRelInfo for which we will fire AFTER STATEMENT triggers.
|
|
|
|
* This is also the relation into whose tuple format all captured transition
|
|
|
|
* tuples must be converted.
|
2009-10-10 03:43:50 +02:00
|
|
|
*/
|
2017-06-28 19:55:03 +02:00
|
|
|
static ResultRelInfo *
|
|
|
|
getASTriggerResultRelInfo(ModifyTableState *node)
|
2009-10-10 03:43:50 +02:00
|
|
|
{
|
2017-05-01 14:23:01 +02:00
|
|
|
/*
|
|
|
|
* If the node modifies a partitioned table, we must fire its triggers.
|
|
|
|
* Note that in that case, node->resultRelInfo points to the first leaf
|
|
|
|
* partition, not the root table.
|
|
|
|
*/
|
|
|
|
if (node->rootResultRelInfo != NULL)
|
2017-06-28 19:55:03 +02:00
|
|
|
return node->rootResultRelInfo;
|
|
|
|
else
|
|
|
|
return node->resultRelInfo;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Process AFTER EACH STATEMENT triggers
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
fireASTriggers(ModifyTableState *node)
|
|
|
|
{
|
|
|
|
ResultRelInfo *resultRelInfo = getASTriggerResultRelInfo(node);
|
2017-05-01 14:23:01 +02:00
|
|
|
|
2009-10-10 03:43:50 +02:00
|
|
|
switch (node->operation)
|
|
|
|
{
|
|
|
|
case CMD_INSERT:
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
if (node->mt_onconflict == ONCONFLICT_UPDATE)
|
|
|
|
ExecASUpdateTriggers(node->ps.state,
|
2017-06-28 19:59:01 +02:00
|
|
|
resultRelInfo,
|
|
|
|
node->mt_transition_capture);
|
|
|
|
ExecASInsertTriggers(node->ps.state, resultRelInfo,
|
|
|
|
node->mt_transition_capture);
|
2009-10-10 03:43:50 +02:00
|
|
|
break;
|
|
|
|
case CMD_UPDATE:
|
2017-06-28 19:59:01 +02:00
|
|
|
ExecASUpdateTriggers(node->ps.state, resultRelInfo,
|
|
|
|
node->mt_transition_capture);
|
2009-10-10 03:43:50 +02:00
|
|
|
break;
|
|
|
|
case CMD_DELETE:
|
2017-06-28 19:59:01 +02:00
|
|
|
ExecASDeleteTriggers(node->ps.state, resultRelInfo,
|
|
|
|
node->mt_transition_capture);
|
2009-10-10 03:43:50 +02:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
elog(ERROR, "unknown operation");
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-06-28 19:55:03 +02:00
|
|
|
/*
|
|
|
|
* Set up the state needed for collecting transition tuples for AFTER
|
|
|
|
* triggers.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
ExecSetupTransitionCaptureState(ModifyTableState *mtstate, EState *estate)
|
|
|
|
{
|
|
|
|
ResultRelInfo *targetRelInfo = getASTriggerResultRelInfo(mtstate);
|
2017-08-14 23:29:33 +02:00
|
|
|
int i;
|
2017-06-28 19:55:03 +02:00
|
|
|
|
|
|
|
/* Check for transition tables on the directly targeted relation. */
|
|
|
|
mtstate->mt_transition_capture =
|
|
|
|
MakeTransitionCaptureState(targetRelInfo->ri_TrigDesc);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we found that we need to collect transition tuples then we may also
|
|
|
|
* need tuple conversion maps for any children that have TupleDescs that
|
|
|
|
* aren't compatible with the tuplestores.
|
|
|
|
*/
|
|
|
|
if (mtstate->mt_transition_capture != NULL)
|
|
|
|
{
|
|
|
|
ResultRelInfo *resultRelInfos;
|
2017-08-14 23:29:33 +02:00
|
|
|
int numResultRelInfos;
|
2017-06-28 19:55:03 +02:00
|
|
|
|
|
|
|
/* Find the set of partitions so that we can find their TupleDescs. */
|
|
|
|
if (mtstate->mt_partition_dispatch_info != NULL)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* For INSERT via partitioned table, so we need TupleDescs based
|
|
|
|
* on the partition routing table.
|
|
|
|
*/
|
|
|
|
resultRelInfos = mtstate->mt_partitions;
|
|
|
|
numResultRelInfos = mtstate->mt_num_partitions;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* Otherwise we need the ResultRelInfo for each subplan. */
|
|
|
|
resultRelInfos = mtstate->resultRelInfo;
|
|
|
|
numResultRelInfos = mtstate->mt_nplans;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Build array of conversion maps from each child's TupleDesc to the
|
|
|
|
* one used in the tuplestore. The map pointers may be NULL when no
|
|
|
|
* conversion is necessary, which is hopefully a common case for
|
|
|
|
* partitions.
|
|
|
|
*/
|
|
|
|
mtstate->mt_transition_tupconv_maps = (TupleConversionMap **)
|
|
|
|
palloc0(sizeof(TupleConversionMap *) * numResultRelInfos);
|
|
|
|
for (i = 0; i < numResultRelInfos; ++i)
|
|
|
|
{
|
|
|
|
mtstate->mt_transition_tupconv_maps[i] =
|
|
|
|
convert_tuples_by_name(RelationGetDescr(resultRelInfos[i].ri_RelationDesc),
|
|
|
|
RelationGetDescr(targetRelInfo->ri_RelationDesc),
|
|
|
|
gettext_noop("could not convert row type"));
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Install the conversion map for the first plan for UPDATE and DELETE
|
|
|
|
* operations. It will be advanced each time we switch to the next
|
|
|
|
* plan. (INSERT operations set it every time.)
|
|
|
|
*/
|
|
|
|
mtstate->mt_transition_capture->tcs_map =
|
|
|
|
mtstate->mt_transition_tupconv_maps[0];
|
|
|
|
}
|
|
|
|
}
|
2009-10-10 03:43:50 +02:00
|
|
|
|
|
|
|
/* ----------------------------------------------------------------
|
|
|
|
* ExecModifyTable
|
|
|
|
*
|
|
|
|
* Perform table modifications as required, and return RETURNING results
|
|
|
|
* if needed.
|
|
|
|
* ----------------------------------------------------------------
|
|
|
|
*/
|
2017-07-17 09:33:49 +02:00
|
|
|
static TupleTableSlot *
|
|
|
|
ExecModifyTable(PlanState *pstate)
|
2009-10-10 03:43:50 +02:00
|
|
|
{
|
2017-07-17 09:33:49 +02:00
|
|
|
ModifyTableState *node = castNode(ModifyTableState, pstate);
|
2010-02-26 03:01:40 +01:00
|
|
|
EState *estate = node->ps.state;
|
|
|
|
CmdType operation = node->operation;
|
2011-02-26 00:56:23 +01:00
|
|
|
ResultRelInfo *saved_resultRelInfo;
|
|
|
|
ResultRelInfo *resultRelInfo;
|
2010-02-26 03:01:40 +01:00
|
|
|
PlanState *subplanstate;
|
2009-10-10 03:43:50 +02:00
|
|
|
JunkFilter *junkfilter;
|
|
|
|
TupleTableSlot *slot;
|
|
|
|
TupleTableSlot *planSlot;
|
|
|
|
ItemPointer tupleid = NULL;
|
|
|
|
ItemPointerData tuple_ctid;
|
2014-03-23 07:16:34 +01:00
|
|
|
HeapTupleData oldtupdata;
|
|
|
|
HeapTuple oldtuple;
|
2009-10-10 03:43:50 +02:00
|
|
|
|
2017-07-26 02:37:17 +02:00
|
|
|
CHECK_FOR_INTERRUPTS();
|
|
|
|
|
2012-01-28 23:43:57 +01:00
|
|
|
/*
|
|
|
|
* This should NOT get called during EvalPlanQual; we should have passed a
|
|
|
|
* subplan tree to EvalPlanQual, instead. Use a runtime test not just
|
|
|
|
* Assert because this condition is easy to miss in testing. (Note:
|
|
|
|
* although ModifyTable should not get executed within an EvalPlanQual
|
|
|
|
* operation, we do have to allow it to be initialized and shut down in
|
|
|
|
* case it is within a CTE subplan. Hence this test must be here, not in
|
|
|
|
* ExecInitModifyTable.)
|
|
|
|
*/
|
|
|
|
if (estate->es_epqTuple != NULL)
|
|
|
|
elog(ERROR, "ModifyTable should not be called during EvalPlanQual");
|
|
|
|
|
2011-02-26 00:56:23 +01:00
|
|
|
/*
|
|
|
|
* If we've already completed processing, don't try to do more. We need
|
|
|
|
* this test because ExecPostprocessPlan might call us an extra time, and
|
|
|
|
* our subplan's nodes aren't necessarily robust against being called
|
|
|
|
* extra times.
|
|
|
|
*/
|
|
|
|
if (node->mt_done)
|
|
|
|
return NULL;
|
|
|
|
|
2009-10-10 03:43:50 +02:00
|
|
|
/*
|
|
|
|
* On first call, fire BEFORE STATEMENT triggers before proceeding.
|
|
|
|
*/
|
|
|
|
if (node->fireBSTriggers)
|
|
|
|
{
|
|
|
|
fireBSTriggers(node);
|
|
|
|
node->fireBSTriggers = false;
|
|
|
|
}
|
|
|
|
|
2011-02-26 00:56:23 +01:00
|
|
|
/* Preload local variables */
|
|
|
|
resultRelInfo = node->resultRelInfo + node->mt_whichplan;
|
|
|
|
subplanstate = node->mt_plans[node->mt_whichplan];
|
|
|
|
junkfilter = resultRelInfo->ri_junkFilter;
|
|
|
|
|
2009-10-10 03:43:50 +02:00
|
|
|
/*
|
|
|
|
* es_result_relation_info must point to the currently active result
|
2014-05-06 18:12:18 +02:00
|
|
|
* relation while we are within this ModifyTable node. Even though
|
2011-02-26 00:56:23 +01:00
|
|
|
* ModifyTable nodes can't be nested statically, they can be nested
|
|
|
|
* dynamically (since our subplan could include a reference to a modifying
|
|
|
|
* CTE). So we have to save and restore the caller's value.
|
2009-10-10 03:43:50 +02:00
|
|
|
*/
|
2011-02-26 00:56:23 +01:00
|
|
|
saved_resultRelInfo = estate->es_result_relation_info;
|
2009-10-10 03:43:50 +02:00
|
|
|
|
2011-02-26 00:56:23 +01:00
|
|
|
estate->es_result_relation_info = resultRelInfo;
|
2009-10-10 03:43:50 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Fetch rows from subplan(s), and execute the required table modification
|
|
|
|
* for each row.
|
|
|
|
*/
|
|
|
|
for (;;)
|
|
|
|
{
|
2010-08-18 23:52:24 +02:00
|
|
|
/*
|
2014-05-06 18:12:18 +02:00
|
|
|
* Reset the per-output-tuple exprcontext. This is needed because
|
2010-08-18 23:52:24 +02:00
|
|
|
* triggers expect to use that context as workspace. It's a bit ugly
|
|
|
|
* to do this below the top level of the plan, however. We might need
|
|
|
|
* to rethink this later.
|
|
|
|
*/
|
|
|
|
ResetPerTupleExprContext(estate);
|
|
|
|
|
2009-10-10 03:43:50 +02:00
|
|
|
planSlot = ExecProcNode(subplanstate);
|
|
|
|
|
|
|
|
if (TupIsNull(planSlot))
|
|
|
|
{
|
|
|
|
/* advance to next subplan if any */
|
|
|
|
node->mt_whichplan++;
|
|
|
|
if (node->mt_whichplan < node->mt_nplans)
|
|
|
|
{
|
2011-02-26 00:56:23 +01:00
|
|
|
resultRelInfo++;
|
2009-10-10 03:43:50 +02:00
|
|
|
subplanstate = node->mt_plans[node->mt_whichplan];
|
2011-02-26 00:56:23 +01:00
|
|
|
junkfilter = resultRelInfo->ri_junkFilter;
|
|
|
|
estate->es_result_relation_info = resultRelInfo;
|
2011-01-13 02:47:02 +01:00
|
|
|
EvalPlanQualSetPlan(&node->mt_epqstate, subplanstate->plan,
|
|
|
|
node->mt_arowmarks[node->mt_whichplan]);
|
2017-06-28 19:55:03 +02:00
|
|
|
if (node->mt_transition_capture != NULL)
|
|
|
|
{
|
|
|
|
/* Prepare to convert transition tuples from this child. */
|
|
|
|
Assert(node->mt_transition_tupconv_maps != NULL);
|
|
|
|
node->mt_transition_capture->tcs_map =
|
|
|
|
node->mt_transition_tupconv_maps[node->mt_whichplan];
|
|
|
|
}
|
2009-10-10 03:43:50 +02:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2016-03-18 18:48:58 +01:00
|
|
|
/*
|
|
|
|
* If resultRelInfo->ri_usesFdwDirectModify is true, all we need to do
|
|
|
|
* here is compute the RETURNING expressions.
|
|
|
|
*/
|
|
|
|
if (resultRelInfo->ri_usesFdwDirectModify)
|
|
|
|
{
|
|
|
|
Assert(resultRelInfo->ri_projectReturning);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* A scan slot containing the data that was actually inserted,
|
|
|
|
* updated or deleted has already been made available to
|
|
|
|
* ExecProcessReturning by IterateDirectModify, so no need to
|
|
|
|
* provide it here.
|
|
|
|
*/
|
|
|
|
slot = ExecProcessReturning(resultRelInfo, NULL, planSlot);
|
|
|
|
|
|
|
|
estate->es_result_relation_info = saved_resultRelInfo;
|
|
|
|
return slot;
|
|
|
|
}
|
|
|
|
|
Re-implement EvalPlanQual processing to improve its performance and eliminate
a lot of strange behaviors that occurred in join cases. We now identify the
"current" row for every joined relation in UPDATE, DELETE, and SELECT FOR
UPDATE/SHARE queries. If an EvalPlanQual recheck is necessary, we jam the
appropriate row into each scan node in the rechecking plan, forcing it to emit
only that one row. The former behavior could rescan the whole of each joined
relation for each recheck, which was terrible for performance, and what's much
worse could result in duplicated output tuples.
Also, the original implementation of EvalPlanQual could not re-use the recheck
execution tree --- it had to go through a full executor init and shutdown for
every row to be tested. To avoid this overhead, I've associated a special
runtime Param with each LockRows or ModifyTable plan node, and arranged to
make every scan node below such a node depend on that Param. Thus, by
signaling a change in that Param, the EPQ machinery can just rescan the
already-built test plan.
This patch also adds a prohibition on set-returning functions in the
targetlist of SELECT FOR UPDATE/SHARE. This is needed to avoid the
duplicate-output-tuple problem. It seems fairly reasonable since the
other restrictions on SELECT FOR UPDATE are meant to ensure that there
is a unique correspondence between source tuples and result tuples,
which an output SRF destroys as much as anything else does.
2009-10-26 03:26:45 +01:00
|
|
|
EvalPlanQualSetSlot(&node->mt_epqstate, planSlot);
|
2009-10-10 03:43:50 +02:00
|
|
|
slot = planSlot;
|
|
|
|
|
2014-03-23 07:16:34 +01:00
|
|
|
oldtuple = NULL;
|
2009-10-10 03:43:50 +02:00
|
|
|
if (junkfilter != NULL)
|
|
|
|
{
|
|
|
|
/*
|
2010-10-10 19:43:33 +02:00
|
|
|
* extract the 'ctid' or 'wholerow' junk attribute.
|
2009-10-10 03:43:50 +02:00
|
|
|
*/
|
|
|
|
if (operation == CMD_UPDATE || operation == CMD_DELETE)
|
|
|
|
{
|
2013-03-10 19:14:53 +01:00
|
|
|
char relkind;
|
2009-10-10 03:43:50 +02:00
|
|
|
Datum datum;
|
|
|
|
bool isNull;
|
|
|
|
|
2013-03-10 19:14:53 +01:00
|
|
|
relkind = resultRelInfo->ri_RelationDesc->rd_rel->relkind;
|
2013-07-16 19:55:44 +02:00
|
|
|
if (relkind == RELKIND_RELATION || relkind == RELKIND_MATVIEW)
|
2010-10-10 19:43:33 +02:00
|
|
|
{
|
|
|
|
datum = ExecGetJunkAttribute(slot,
|
|
|
|
junkfilter->jf_junkAttNo,
|
|
|
|
&isNull);
|
|
|
|
/* shouldn't ever get a null result... */
|
|
|
|
if (isNull)
|
|
|
|
elog(ERROR, "ctid is NULL");
|
|
|
|
|
|
|
|
tupleid = (ItemPointer) DatumGetPointer(datum);
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
tuple_ctid = *tupleid; /* be sure we don't free ctid!! */
|
2010-10-10 19:43:33 +02:00
|
|
|
tupleid = &tuple_ctid;
|
|
|
|
}
|
2014-05-06 18:12:18 +02:00
|
|
|
|
2014-03-23 07:16:34 +01:00
|
|
|
/*
|
|
|
|
* Use the wholerow attribute, when available, to reconstruct
|
|
|
|
* the old relation tuple.
|
|
|
|
*
|
|
|
|
* Foreign table updates have a wholerow attribute when the
|
2017-08-03 18:47:00 +02:00
|
|
|
* relation has a row-level trigger. Note that the wholerow
|
2014-03-23 07:16:34 +01:00
|
|
|
* attribute does not carry system columns. Foreign table
|
|
|
|
* triggers miss seeing those, except that we know enough here
|
|
|
|
* to set t_tableOid. Quite separately from this, the FDW may
|
|
|
|
* fetch its own junk attrs to identify the row.
|
|
|
|
*
|
|
|
|
* Other relevant relkinds, currently limited to views, always
|
|
|
|
* have a wholerow attribute.
|
|
|
|
*/
|
|
|
|
else if (AttributeNumberIsValid(junkfilter->jf_junkAttNo))
|
2010-10-10 19:43:33 +02:00
|
|
|
{
|
|
|
|
datum = ExecGetJunkAttribute(slot,
|
|
|
|
junkfilter->jf_junkAttNo,
|
|
|
|
&isNull);
|
|
|
|
/* shouldn't ever get a null result... */
|
|
|
|
if (isNull)
|
|
|
|
elog(ERROR, "wholerow is NULL");
|
|
|
|
|
2014-03-23 07:16:34 +01:00
|
|
|
oldtupdata.t_data = DatumGetHeapTupleHeader(datum);
|
|
|
|
oldtupdata.t_len =
|
|
|
|
HeapTupleHeaderGetDatumLength(oldtupdata.t_data);
|
|
|
|
ItemPointerSetInvalid(&(oldtupdata.t_self));
|
|
|
|
/* Historically, view triggers see invalid t_tableOid. */
|
|
|
|
oldtupdata.t_tableOid =
|
|
|
|
(relkind == RELKIND_VIEW) ? InvalidOid :
|
|
|
|
RelationGetRelid(resultRelInfo->ri_RelationDesc);
|
|
|
|
|
|
|
|
oldtuple = &oldtupdata;
|
2010-10-10 19:43:33 +02:00
|
|
|
}
|
2014-03-23 07:16:34 +01:00
|
|
|
else
|
|
|
|
Assert(relkind == RELKIND_FOREIGN_TABLE);
|
2009-10-10 03:43:50 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* apply the junkfilter if needed.
|
|
|
|
*/
|
|
|
|
if (operation != CMD_DELETE)
|
|
|
|
slot = ExecFilterJunk(junkfilter, slot);
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (operation)
|
|
|
|
{
|
|
|
|
case CMD_INSERT:
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
slot = ExecInsert(node, slot, planSlot,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
node->mt_arbiterindexes, node->mt_onconflict,
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
estate, node->canSetTag);
|
2009-10-10 03:43:50 +02:00
|
|
|
break;
|
|
|
|
case CMD_UPDATE:
|
2017-06-28 19:55:03 +02:00
|
|
|
slot = ExecUpdate(node, tupleid, oldtuple, slot, planSlot,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
&node->mt_epqstate, estate, node->canSetTag);
|
2009-10-10 03:43:50 +02:00
|
|
|
break;
|
|
|
|
case CMD_DELETE:
|
2017-06-28 19:55:03 +02:00
|
|
|
slot = ExecDelete(node, tupleid, oldtuple, planSlot,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
&node->mt_epqstate, estate, node->canSetTag);
|
2009-10-10 03:43:50 +02:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
elog(ERROR, "unknown operation");
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we got a RETURNING result, return it to caller. We'll continue
|
|
|
|
* the work on next call.
|
|
|
|
*/
|
|
|
|
if (slot)
|
|
|
|
{
|
2011-02-26 00:56:23 +01:00
|
|
|
estate->es_result_relation_info = saved_resultRelInfo;
|
2009-10-10 03:43:50 +02:00
|
|
|
return slot;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-02-26 00:56:23 +01:00
|
|
|
/* Restore es_result_relation_info before exiting */
|
|
|
|
estate->es_result_relation_info = saved_resultRelInfo;
|
2009-10-10 03:43:50 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We're done, but fire AFTER STATEMENT triggers before exiting.
|
|
|
|
*/
|
|
|
|
fireASTriggers(node);
|
|
|
|
|
2011-02-26 00:56:23 +01:00
|
|
|
node->mt_done = true;
|
|
|
|
|
2009-10-10 03:43:50 +02:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* ----------------------------------------------------------------
|
|
|
|
* ExecInitModifyTable
|
|
|
|
* ----------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
ModifyTableState *
|
|
|
|
ExecInitModifyTable(ModifyTable *node, EState *estate, int eflags)
|
|
|
|
{
|
|
|
|
ModifyTableState *mtstate;
|
|
|
|
CmdType operation = node->operation;
|
|
|
|
int nplans = list_length(node->plans);
|
2011-02-26 00:56:23 +01:00
|
|
|
ResultRelInfo *saved_resultRelInfo;
|
2009-10-10 03:43:50 +02:00
|
|
|
ResultRelInfo *resultRelInfo;
|
|
|
|
TupleDesc tupDesc;
|
|
|
|
Plan *subplan;
|
|
|
|
ListCell *l;
|
|
|
|
int i;
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
Relation rel;
|
2009-10-10 03:43:50 +02:00
|
|
|
|
|
|
|
/* check for unsupported flags */
|
|
|
|
Assert(!(eflags & (EXEC_FLAG_BACKWARD | EXEC_FLAG_MARK)));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* create state structure
|
|
|
|
*/
|
|
|
|
mtstate = makeNode(ModifyTableState);
|
|
|
|
mtstate->ps.plan = (Plan *) node;
|
|
|
|
mtstate->ps.state = estate;
|
2017-07-17 09:33:49 +02:00
|
|
|
mtstate->ps.ExecProcNode = ExecModifyTable;
|
2009-10-10 03:43:50 +02:00
|
|
|
|
2011-02-26 00:56:23 +01:00
|
|
|
mtstate->operation = operation;
|
|
|
|
mtstate->canSetTag = node->canSetTag;
|
|
|
|
mtstate->mt_done = false;
|
|
|
|
|
2009-10-10 03:43:50 +02:00
|
|
|
mtstate->mt_plans = (PlanState **) palloc0(sizeof(PlanState *) * nplans);
|
2011-02-26 00:56:23 +01:00
|
|
|
mtstate->resultRelInfo = estate->es_result_relations + node->resultRelIndex;
|
2017-05-01 14:23:01 +02:00
|
|
|
|
|
|
|
/* If modifying a partitioned table, initialize the root table info */
|
|
|
|
if (node->rootResultRelIndex >= 0)
|
|
|
|
mtstate->rootResultRelInfo = estate->es_root_result_relations +
|
2017-05-17 22:31:56 +02:00
|
|
|
node->rootResultRelIndex;
|
2017-05-01 14:23:01 +02:00
|
|
|
|
2011-01-13 02:47:02 +01:00
|
|
|
mtstate->mt_arowmarks = (List **) palloc0(sizeof(List *) * nplans);
|
2009-10-10 03:43:50 +02:00
|
|
|
mtstate->mt_nplans = nplans;
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
mtstate->mt_onconflict = node->onConflictAction;
|
|
|
|
mtstate->mt_arbiterindexes = node->arbiterIndexes;
|
2011-02-26 00:56:23 +01:00
|
|
|
|
2011-01-13 02:47:02 +01:00
|
|
|
/* set up epqstate with dummy subplan data for the moment */
|
|
|
|
EvalPlanQualInit(&mtstate->mt_epqstate, estate, NULL, NIL, node->epqParam);
|
2009-10-10 03:43:50 +02:00
|
|
|
mtstate->fireBSTriggers = true;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* call ExecInitNode on each of the plans to be executed and save the
|
2011-04-10 17:42:00 +02:00
|
|
|
* results into the array "mt_plans". This is also a convenient place to
|
|
|
|
* verify that the proposed target relations are valid and open their
|
2014-05-06 18:12:18 +02:00
|
|
|
* indexes for insertion of new index entries. Note we *must* set
|
2009-10-10 03:43:50 +02:00
|
|
|
* estate->es_result_relation_info correctly while we initialize each
|
|
|
|
* sub-plan; ExecContextForcesOids depends on that!
|
|
|
|
*/
|
2011-02-26 00:56:23 +01:00
|
|
|
saved_resultRelInfo = estate->es_result_relation_info;
|
|
|
|
|
|
|
|
resultRelInfo = mtstate->resultRelInfo;
|
2009-10-10 03:43:50 +02:00
|
|
|
i = 0;
|
|
|
|
foreach(l, node->plans)
|
|
|
|
{
|
|
|
|
subplan = (Plan *) lfirst(l);
|
2011-02-26 00:56:23 +01:00
|
|
|
|
2016-03-18 18:48:58 +01:00
|
|
|
/* Initialize the usesFdwDirectModify flag */
|
|
|
|
resultRelInfo->ri_usesFdwDirectModify = bms_is_member(i,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
node->fdwDirectModifyPlans);
|
2016-03-18 18:48:58 +01:00
|
|
|
|
2011-02-26 00:56:23 +01:00
|
|
|
/*
|
|
|
|
* Verify result relation is a valid target for the current operation
|
|
|
|
*/
|
|
|
|
CheckValidResultRel(resultRelInfo->ri_RelationDesc, operation);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If there are indices on the result relation, open them and save
|
|
|
|
* descriptors in the result relation info, so that we can add new
|
2014-05-06 18:12:18 +02:00
|
|
|
* index entries for the tuples we add/update. We need not do this
|
2012-06-10 21:20:04 +02:00
|
|
|
* for a DELETE, however, since deletion doesn't affect indexes. Also,
|
|
|
|
* inside an EvalPlanQual operation, the indexes might be open
|
2012-01-28 23:43:57 +01:00
|
|
|
* already, since we share the resultrel state with the original
|
|
|
|
* query.
|
2011-02-26 00:56:23 +01:00
|
|
|
*/
|
|
|
|
if (resultRelInfo->ri_RelationDesc->rd_rel->relhasindex &&
|
2012-01-28 23:43:57 +01:00
|
|
|
operation != CMD_DELETE &&
|
|
|
|
resultRelInfo->ri_IndexRelationDescs == NULL)
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
ExecOpenIndices(resultRelInfo, mtstate->mt_onconflict != ONCONFLICT_NONE);
|
2011-02-26 00:56:23 +01:00
|
|
|
|
|
|
|
/* Now init the plan for this result rel */
|
|
|
|
estate->es_result_relation_info = resultRelInfo;
|
2009-10-10 03:43:50 +02:00
|
|
|
mtstate->mt_plans[i] = ExecInitNode(subplan, estate, eflags);
|
2011-02-26 00:56:23 +01:00
|
|
|
|
2013-03-10 19:14:53 +01:00
|
|
|
/* Also let FDWs init themselves for foreign-table result rels */
|
2016-03-18 18:48:58 +01:00
|
|
|
if (!resultRelInfo->ri_usesFdwDirectModify &&
|
|
|
|
resultRelInfo->ri_FdwRoutine != NULL &&
|
2013-03-10 19:14:53 +01:00
|
|
|
resultRelInfo->ri_FdwRoutine->BeginForeignModify != NULL)
|
|
|
|
{
|
|
|
|
List *fdw_private = (List *) list_nth(node->fdwPrivLists, i);
|
|
|
|
|
|
|
|
resultRelInfo->ri_FdwRoutine->BeginForeignModify(mtstate,
|
|
|
|
resultRelInfo,
|
|
|
|
fdw_private,
|
|
|
|
i,
|
|
|
|
eflags);
|
|
|
|
}
|
|
|
|
|
2011-02-26 00:56:23 +01:00
|
|
|
resultRelInfo++;
|
2009-10-10 03:43:50 +02:00
|
|
|
i++;
|
|
|
|
}
|
2011-02-26 00:56:23 +01:00
|
|
|
|
|
|
|
estate->es_result_relation_info = saved_resultRelInfo;
|
2009-10-10 03:43:50 +02:00
|
|
|
|
2017-03-21 14:48:04 +01:00
|
|
|
/* The root table RT index is at the head of the partitioned_rels list */
|
|
|
|
if (node->partitioned_rels)
|
|
|
|
{
|
2017-05-17 22:31:56 +02:00
|
|
|
Index root_rti;
|
|
|
|
Oid root_oid;
|
2017-03-21 14:48:04 +01:00
|
|
|
|
|
|
|
root_rti = linitial_int(node->partitioned_rels);
|
|
|
|
root_oid = getrelid(root_rti, estate->es_range_table);
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
rel = heap_open(root_oid, NoLock); /* locked by InitPlan */
|
2017-03-21 14:48:04 +01:00
|
|
|
}
|
|
|
|
else
|
|
|
|
rel = mtstate->resultRelInfo->ri_RelationDesc;
|
|
|
|
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
/* Build state for INSERT tuple routing */
|
|
|
|
if (operation == CMD_INSERT &&
|
|
|
|
rel->rd_rel->relkind == RELKIND_PARTITIONED_TABLE)
|
|
|
|
{
|
2017-01-24 16:20:02 +01:00
|
|
|
PartitionDispatch *partition_dispatch_info;
|
|
|
|
ResultRelInfo *partitions;
|
2016-12-21 17:36:10 +01:00
|
|
|
TupleConversionMap **partition_tupconv_maps;
|
2017-01-24 16:20:02 +01:00
|
|
|
TupleTableSlot *partition_tuple_slot;
|
|
|
|
int num_parted,
|
|
|
|
num_partitions;
|
2016-12-21 17:36:10 +01:00
|
|
|
|
|
|
|
ExecSetupPartitionTupleRouting(rel,
|
2017-07-18 03:29:45 +02:00
|
|
|
node->nominalRelation,
|
2016-12-21 17:36:10 +01:00
|
|
|
&partition_dispatch_info,
|
|
|
|
&partitions,
|
|
|
|
&partition_tupconv_maps,
|
2017-01-04 19:05:29 +01:00
|
|
|
&partition_tuple_slot,
|
2016-12-21 17:36:10 +01:00
|
|
|
&num_parted, &num_partitions);
|
|
|
|
mtstate->mt_partition_dispatch_info = partition_dispatch_info;
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
mtstate->mt_num_dispatch = num_parted;
|
2016-12-21 17:36:10 +01:00
|
|
|
mtstate->mt_partitions = partitions;
|
|
|
|
mtstate->mt_num_partitions = num_partitions;
|
|
|
|
mtstate->mt_partition_tupconv_maps = partition_tupconv_maps;
|
2017-01-04 19:05:29 +01:00
|
|
|
mtstate->mt_partition_tuple_slot = partition_tuple_slot;
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
}
|
|
|
|
|
2017-06-28 19:55:03 +02:00
|
|
|
/* Build state for collecting transition tuples */
|
|
|
|
ExecSetupTransitionCaptureState(mtstate, estate);
|
|
|
|
|
2013-07-18 23:10:16 +02:00
|
|
|
/*
|
|
|
|
* Initialize any WITH CHECK OPTION constraints if needed.
|
|
|
|
*/
|
|
|
|
resultRelInfo = mtstate->resultRelInfo;
|
|
|
|
i = 0;
|
|
|
|
foreach(l, node->withCheckOptionLists)
|
|
|
|
{
|
|
|
|
List *wcoList = (List *) lfirst(l);
|
|
|
|
List *wcoExprs = NIL;
|
|
|
|
ListCell *ll;
|
|
|
|
|
|
|
|
foreach(ll, wcoList)
|
|
|
|
{
|
|
|
|
WithCheckOption *wco = (WithCheckOption *) lfirst(ll);
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
ExprState *wcoExpr = ExecInitQual((List *) wco->qual,
|
2013-07-18 23:10:16 +02:00
|
|
|
mtstate->mt_plans[i]);
|
2014-05-06 18:12:18 +02:00
|
|
|
|
2013-07-18 23:10:16 +02:00
|
|
|
wcoExprs = lappend(wcoExprs, wcoExpr);
|
|
|
|
}
|
|
|
|
|
|
|
|
resultRelInfo->ri_WithCheckOptions = wcoList;
|
|
|
|
resultRelInfo->ri_WithCheckOptionExprs = wcoExprs;
|
|
|
|
resultRelInfo++;
|
|
|
|
i++;
|
|
|
|
}
|
|
|
|
|
2017-01-24 21:46:50 +01:00
|
|
|
/*
|
2017-05-17 22:31:56 +02:00
|
|
|
* Build WITH CHECK OPTION constraints for each leaf partition rel. Note
|
|
|
|
* that we didn't build the withCheckOptionList for each partition within
|
|
|
|
* the planner, but simple translation of the varattnos for each partition
|
|
|
|
* will suffice. This only occurs for the INSERT case; UPDATE/DELETE
|
|
|
|
* cases are handled above.
|
2017-01-24 21:46:50 +01:00
|
|
|
*/
|
|
|
|
if (node->withCheckOptionLists != NIL && mtstate->mt_num_partitions > 0)
|
|
|
|
{
|
2017-05-17 22:31:56 +02:00
|
|
|
List *wcoList;
|
2017-06-13 05:29:44 +02:00
|
|
|
PlanState *plan;
|
2017-01-24 21:46:50 +01:00
|
|
|
|
2017-06-13 05:29:44 +02:00
|
|
|
/*
|
|
|
|
* In case of INSERT on partitioned tables, there is only one plan.
|
|
|
|
* Likewise, there is only one WITH CHECK OPTIONS list, not one per
|
|
|
|
* partition. We make a copy of the WCO qual for each partition; note
|
|
|
|
* that, if there are SubPlans in there, they all end up attached to
|
|
|
|
* the one parent Plan node.
|
|
|
|
*/
|
|
|
|
Assert(operation == CMD_INSERT &&
|
|
|
|
list_length(node->withCheckOptionLists) == 1 &&
|
|
|
|
mtstate->mt_nplans == 1);
|
2017-01-24 21:46:50 +01:00
|
|
|
wcoList = linitial(node->withCheckOptionLists);
|
2017-06-13 05:29:44 +02:00
|
|
|
plan = mtstate->mt_plans[0];
|
|
|
|
resultRelInfo = mtstate->mt_partitions;
|
2017-01-24 21:46:50 +01:00
|
|
|
for (i = 0; i < mtstate->mt_num_partitions; i++)
|
|
|
|
{
|
|
|
|
Relation partrel = resultRelInfo->ri_RelationDesc;
|
|
|
|
List *mapped_wcoList;
|
|
|
|
List *wcoExprs = NIL;
|
|
|
|
ListCell *ll;
|
|
|
|
|
|
|
|
/* varno = node->nominalRelation */
|
|
|
|
mapped_wcoList = map_partition_varattnos(wcoList,
|
|
|
|
node->nominalRelation,
|
2017-08-03 17:21:29 +02:00
|
|
|
partrel, rel, NULL);
|
2017-01-24 21:46:50 +01:00
|
|
|
foreach(ll, mapped_wcoList)
|
|
|
|
{
|
2017-06-13 05:29:44 +02:00
|
|
|
WithCheckOption *wco = castNode(WithCheckOption, lfirst(ll));
|
|
|
|
ExprState *wcoExpr = ExecInitQual(castNode(List, wco->qual),
|
|
|
|
plan);
|
2017-01-24 21:46:50 +01:00
|
|
|
|
|
|
|
wcoExprs = lappend(wcoExprs, wcoExpr);
|
|
|
|
}
|
|
|
|
|
|
|
|
resultRelInfo->ri_WithCheckOptions = mapped_wcoList;
|
|
|
|
resultRelInfo->ri_WithCheckOptionExprs = wcoExprs;
|
|
|
|
resultRelInfo++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-10-10 03:43:50 +02:00
|
|
|
/*
|
|
|
|
* Initialize RETURNING projections if needed.
|
|
|
|
*/
|
|
|
|
if (node->returningLists)
|
|
|
|
{
|
|
|
|
TupleTableSlot *slot;
|
|
|
|
ExprContext *econtext;
|
2017-01-24 16:20:02 +01:00
|
|
|
List *returningList;
|
2009-10-10 03:43:50 +02:00
|
|
|
|
|
|
|
/*
|
2010-02-26 03:01:40 +01:00
|
|
|
* Initialize result tuple slot and assign its rowtype using the first
|
2014-05-06 18:12:18 +02:00
|
|
|
* RETURNING list. We assume the rest will look the same.
|
2009-10-10 03:43:50 +02:00
|
|
|
*/
|
|
|
|
tupDesc = ExecTypeFromTL((List *) linitial(node->returningLists),
|
|
|
|
false);
|
|
|
|
|
|
|
|
/* Set up a slot for the output of the RETURNING projection(s) */
|
|
|
|
ExecInitResultTupleSlot(estate, &mtstate->ps);
|
|
|
|
ExecAssignResultType(&mtstate->ps, tupDesc);
|
|
|
|
slot = mtstate->ps.ps_ResultTupleSlot;
|
|
|
|
|
|
|
|
/* Need an econtext too */
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
if (mtstate->ps.ps_ExprContext == NULL)
|
|
|
|
ExecAssignExprContext(estate, &mtstate->ps);
|
|
|
|
econtext = mtstate->ps.ps_ExprContext;
|
2009-10-10 03:43:50 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Build a projection for each result rel.
|
|
|
|
*/
|
2011-02-26 00:56:23 +01:00
|
|
|
resultRelInfo = mtstate->resultRelInfo;
|
2009-10-10 03:43:50 +02:00
|
|
|
foreach(l, node->returningLists)
|
|
|
|
{
|
|
|
|
List *rlist = (List *) lfirst(l);
|
|
|
|
|
|
|
|
resultRelInfo->ri_projectReturning =
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
ExecBuildProjectionInfo(rlist, econtext, slot, &mtstate->ps,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
resultRelInfo->ri_RelationDesc->rd_att);
|
2009-10-10 03:43:50 +02:00
|
|
|
resultRelInfo++;
|
|
|
|
}
|
2017-01-19 19:20:11 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Build a projection for each leaf partition rel. Note that we
|
|
|
|
* didn't build the returningList for each partition within the
|
2017-01-24 16:20:02 +01:00
|
|
|
* planner, but simple translation of the varattnos for each partition
|
|
|
|
* will suffice. This only occurs for the INSERT case; UPDATE/DELETE
|
|
|
|
* are handled above.
|
2017-01-19 19:20:11 +01:00
|
|
|
*/
|
|
|
|
resultRelInfo = mtstate->mt_partitions;
|
|
|
|
returningList = linitial(node->returningLists);
|
|
|
|
for (i = 0; i < mtstate->mt_num_partitions; i++)
|
|
|
|
{
|
|
|
|
Relation partrel = resultRelInfo->ri_RelationDesc;
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
List *rlist;
|
2017-01-19 19:20:11 +01:00
|
|
|
|
|
|
|
/* varno = node->nominalRelation */
|
|
|
|
rlist = map_partition_varattnos(returningList,
|
|
|
|
node->nominalRelation,
|
2017-08-03 17:21:29 +02:00
|
|
|
partrel, rel, NULL);
|
2017-01-19 19:20:11 +01:00
|
|
|
resultRelInfo->ri_projectReturning =
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
ExecBuildProjectionInfo(rlist, econtext, slot, &mtstate->ps,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
resultRelInfo->ri_RelationDesc->rd_att);
|
2017-01-19 19:20:11 +01:00
|
|
|
resultRelInfo++;
|
|
|
|
}
|
2009-10-10 03:43:50 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/*
|
2010-02-26 03:01:40 +01:00
|
|
|
* We still must construct a dummy result tuple type, because InitPlan
|
|
|
|
* expects one (maybe should change that?).
|
2009-10-10 03:43:50 +02:00
|
|
|
*/
|
|
|
|
tupDesc = ExecTypeFromTL(NIL, false);
|
|
|
|
ExecInitResultTupleSlot(estate, &mtstate->ps);
|
|
|
|
ExecAssignResultType(&mtstate->ps, tupDesc);
|
|
|
|
|
|
|
|
mtstate->ps.ps_ExprContext = NULL;
|
|
|
|
}
|
|
|
|
|
2017-03-21 14:48:04 +01:00
|
|
|
/* Close the root partitioned rel if we opened it above. */
|
|
|
|
if (rel != mtstate->resultRelInfo->ri_RelationDesc)
|
|
|
|
heap_close(rel, NoLock);
|
|
|
|
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
/*
|
|
|
|
* If needed, Initialize target list, projection and qual for ON CONFLICT
|
|
|
|
* DO UPDATE.
|
|
|
|
*/
|
|
|
|
resultRelInfo = mtstate->resultRelInfo;
|
|
|
|
if (node->onConflictAction == ONCONFLICT_UPDATE)
|
|
|
|
{
|
|
|
|
ExprContext *econtext;
|
|
|
|
TupleDesc tupDesc;
|
|
|
|
|
|
|
|
/* insert may only have one plan, inheritance is not expanded */
|
|
|
|
Assert(nplans == 1);
|
|
|
|
|
|
|
|
/* already exists if created by RETURNING processing above */
|
|
|
|
if (mtstate->ps.ps_ExprContext == NULL)
|
|
|
|
ExecAssignExprContext(estate, &mtstate->ps);
|
|
|
|
|
|
|
|
econtext = mtstate->ps.ps_ExprContext;
|
|
|
|
|
|
|
|
/* initialize slot for the existing tuple */
|
|
|
|
mtstate->mt_existing = ExecInitExtraTupleSlot(mtstate->ps.state);
|
|
|
|
ExecSetSlotDescriptor(mtstate->mt_existing,
|
|
|
|
resultRelInfo->ri_RelationDesc->rd_att);
|
|
|
|
|
2015-05-13 00:13:22 +02:00
|
|
|
/* carried forward solely for the benefit of explain */
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
mtstate->mt_excludedtlist = node->exclRelTlist;
|
|
|
|
|
|
|
|
/* create target slot for UPDATE SET projection */
|
|
|
|
tupDesc = ExecTypeFromTL((List *) node->onConflictSet,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
resultRelInfo->ri_RelationDesc->rd_rel->relhasoids);
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
mtstate->mt_conflproj = ExecInitExtraTupleSlot(mtstate->ps.state);
|
|
|
|
ExecSetSlotDescriptor(mtstate->mt_conflproj, tupDesc);
|
|
|
|
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
/* build UPDATE SET projection state */
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
resultRelInfo->ri_onConflictSetProj =
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
ExecBuildProjectionInfo(node->onConflictSet, econtext,
|
|
|
|
mtstate->mt_conflproj, &mtstate->ps,
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
resultRelInfo->ri_RelationDesc->rd_att);
|
|
|
|
|
|
|
|
/* build DO UPDATE WHERE clause expression */
|
|
|
|
if (node->onConflictWhere)
|
|
|
|
{
|
|
|
|
ExprState *qualexpr;
|
|
|
|
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
qualexpr = ExecInitQual((List *) node->onConflictWhere,
|
2015-05-19 01:55:10 +02:00
|
|
|
&mtstate->ps);
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
resultRelInfo->ri_onConflictSetWhere = qualexpr;
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Re-implement EvalPlanQual processing to improve its performance and eliminate
a lot of strange behaviors that occurred in join cases. We now identify the
"current" row for every joined relation in UPDATE, DELETE, and SELECT FOR
UPDATE/SHARE queries. If an EvalPlanQual recheck is necessary, we jam the
appropriate row into each scan node in the rechecking plan, forcing it to emit
only that one row. The former behavior could rescan the whole of each joined
relation for each recheck, which was terrible for performance, and what's much
worse could result in duplicated output tuples.
Also, the original implementation of EvalPlanQual could not re-use the recheck
execution tree --- it had to go through a full executor init and shutdown for
every row to be tested. To avoid this overhead, I've associated a special
runtime Param with each LockRows or ModifyTable plan node, and arranged to
make every scan node below such a node depend on that Param. Thus, by
signaling a change in that Param, the EPQ machinery can just rescan the
already-built test plan.
This patch also adds a prohibition on set-returning functions in the
targetlist of SELECT FOR UPDATE/SHARE. This is needed to avoid the
duplicate-output-tuple problem. It seems fairly reasonable since the
other restrictions on SELECT FOR UPDATE are meant to ensure that there
is a unique correspondence between source tuples and result tuples,
which an output SRF destroys as much as anything else does.
2009-10-26 03:26:45 +01:00
|
|
|
/*
|
2010-02-26 03:01:40 +01:00
|
|
|
* If we have any secondary relations in an UPDATE or DELETE, they need to
|
|
|
|
* be treated like non-locked relations in SELECT FOR UPDATE, ie, the
|
2014-05-06 18:12:18 +02:00
|
|
|
* EvalPlanQual mechanism needs to be told about them. Locate the
|
2010-02-26 03:01:40 +01:00
|
|
|
* relevant ExecRowMarks.
|
Re-implement EvalPlanQual processing to improve its performance and eliminate
a lot of strange behaviors that occurred in join cases. We now identify the
"current" row for every joined relation in UPDATE, DELETE, and SELECT FOR
UPDATE/SHARE queries. If an EvalPlanQual recheck is necessary, we jam the
appropriate row into each scan node in the rechecking plan, forcing it to emit
only that one row. The former behavior could rescan the whole of each joined
relation for each recheck, which was terrible for performance, and what's much
worse could result in duplicated output tuples.
Also, the original implementation of EvalPlanQual could not re-use the recheck
execution tree --- it had to go through a full executor init and shutdown for
every row to be tested. To avoid this overhead, I've associated a special
runtime Param with each LockRows or ModifyTable plan node, and arranged to
make every scan node below such a node depend on that Param. Thus, by
signaling a change in that Param, the EPQ machinery can just rescan the
already-built test plan.
This patch also adds a prohibition on set-returning functions in the
targetlist of SELECT FOR UPDATE/SHARE. This is needed to avoid the
duplicate-output-tuple problem. It seems fairly reasonable since the
other restrictions on SELECT FOR UPDATE are meant to ensure that there
is a unique correspondence between source tuples and result tuples,
which an output SRF destroys as much as anything else does.
2009-10-26 03:26:45 +01:00
|
|
|
*/
|
|
|
|
foreach(l, node->rowMarks)
|
|
|
|
{
|
Improve castNode notation by introducing list-extraction-specific variants.
This extends the castNode() notation introduced by commit 5bcab1114 to
provide, in one step, extraction of a list cell's pointer and coercion to
a concrete node type. For example, "lfirst_node(Foo, lc)" is the same
as "castNode(Foo, lfirst(lc))". Almost half of the uses of castNode
that have appeared so far include a list extraction call, so this is
pretty widely useful, and it saves a few more keystrokes compared to the
old way.
As with the previous patch, back-patch the addition of these macros to
pg_list.h, so that the notation will be available when back-patching.
Patch by me, after an idea of Andrew Gierth's.
Discussion: https://postgr.es/m/14197.1491841216@sss.pgh.pa.us
2017-04-10 19:51:29 +02:00
|
|
|
PlanRowMark *rc = lfirst_node(PlanRowMark, l);
|
2011-01-13 02:47:02 +01:00
|
|
|
ExecRowMark *erm;
|
Re-implement EvalPlanQual processing to improve its performance and eliminate
a lot of strange behaviors that occurred in join cases. We now identify the
"current" row for every joined relation in UPDATE, DELETE, and SELECT FOR
UPDATE/SHARE queries. If an EvalPlanQual recheck is necessary, we jam the
appropriate row into each scan node in the rechecking plan, forcing it to emit
only that one row. The former behavior could rescan the whole of each joined
relation for each recheck, which was terrible for performance, and what's much
worse could result in duplicated output tuples.
Also, the original implementation of EvalPlanQual could not re-use the recheck
execution tree --- it had to go through a full executor init and shutdown for
every row to be tested. To avoid this overhead, I've associated a special
runtime Param with each LockRows or ModifyTable plan node, and arranged to
make every scan node below such a node depend on that Param. Thus, by
signaling a change in that Param, the EPQ machinery can just rescan the
already-built test plan.
This patch also adds a prohibition on set-returning functions in the
targetlist of SELECT FOR UPDATE/SHARE. This is needed to avoid the
duplicate-output-tuple problem. It seems fairly reasonable since the
other restrictions on SELECT FOR UPDATE are meant to ensure that there
is a unique correspondence between source tuples and result tuples,
which an output SRF destroys as much as anything else does.
2009-10-26 03:26:45 +01:00
|
|
|
|
|
|
|
/* ignore "parent" rowmarks; they are irrelevant at runtime */
|
|
|
|
if (rc->isParent)
|
|
|
|
continue;
|
|
|
|
|
2011-01-13 02:47:02 +01:00
|
|
|
/* find ExecRowMark (same for all subplans) */
|
Add support for doing late row locking in FDWs.
Previously, FDWs could only do "early row locking", that is lock a row as
soon as it's fetched, even though local restriction/join conditions might
discard the row later. This patch adds callbacks that allow FDWs to do
late locking in the same way that it's done for regular tables.
To make use of this feature, an FDW must support the "ctid" column as a
unique row identifier. Currently, since ctid has to be of type TID,
the feature is of limited use, though in principle it could be used by
postgres_fdw. We may eventually allow FDWs to specify another data type
for ctid, which would make it possible for more FDWs to use this feature.
This commit does not modify postgres_fdw to use late locking. We've
tested some prototype code for that, but it's not in committable shape,
and besides it's quite unclear whether it actually makes sense to do late
locking against a remote server. The extra round trips required are likely
to outweigh any benefit from improved concurrency.
Etsuro Fujita, reviewed by Ashutosh Bapat, and hacked up a lot by me
2015-05-12 20:10:10 +02:00
|
|
|
erm = ExecFindRowMark(estate, rc->rti, false);
|
2011-01-13 02:47:02 +01:00
|
|
|
|
|
|
|
/* build ExecAuxRowMark for each subplan */
|
|
|
|
for (i = 0; i < nplans; i++)
|
Re-implement EvalPlanQual processing to improve its performance and eliminate
a lot of strange behaviors that occurred in join cases. We now identify the
"current" row for every joined relation in UPDATE, DELETE, and SELECT FOR
UPDATE/SHARE queries. If an EvalPlanQual recheck is necessary, we jam the
appropriate row into each scan node in the rechecking plan, forcing it to emit
only that one row. The former behavior could rescan the whole of each joined
relation for each recheck, which was terrible for performance, and what's much
worse could result in duplicated output tuples.
Also, the original implementation of EvalPlanQual could not re-use the recheck
execution tree --- it had to go through a full executor init and shutdown for
every row to be tested. To avoid this overhead, I've associated a special
runtime Param with each LockRows or ModifyTable plan node, and arranged to
make every scan node below such a node depend on that Param. Thus, by
signaling a change in that Param, the EPQ machinery can just rescan the
already-built test plan.
This patch also adds a prohibition on set-returning functions in the
targetlist of SELECT FOR UPDATE/SHARE. This is needed to avoid the
duplicate-output-tuple problem. It seems fairly reasonable since the
other restrictions on SELECT FOR UPDATE are meant to ensure that there
is a unique correspondence between source tuples and result tuples,
which an output SRF destroys as much as anything else does.
2009-10-26 03:26:45 +01:00
|
|
|
{
|
2011-01-13 02:47:02 +01:00
|
|
|
ExecAuxRowMark *aerm;
|
Re-implement EvalPlanQual processing to improve its performance and eliminate
a lot of strange behaviors that occurred in join cases. We now identify the
"current" row for every joined relation in UPDATE, DELETE, and SELECT FOR
UPDATE/SHARE queries. If an EvalPlanQual recheck is necessary, we jam the
appropriate row into each scan node in the rechecking plan, forcing it to emit
only that one row. The former behavior could rescan the whole of each joined
relation for each recheck, which was terrible for performance, and what's much
worse could result in duplicated output tuples.
Also, the original implementation of EvalPlanQual could not re-use the recheck
execution tree --- it had to go through a full executor init and shutdown for
every row to be tested. To avoid this overhead, I've associated a special
runtime Param with each LockRows or ModifyTable plan node, and arranged to
make every scan node below such a node depend on that Param. Thus, by
signaling a change in that Param, the EPQ machinery can just rescan the
already-built test plan.
This patch also adds a prohibition on set-returning functions in the
targetlist of SELECT FOR UPDATE/SHARE. This is needed to avoid the
duplicate-output-tuple problem. It seems fairly reasonable since the
other restrictions on SELECT FOR UPDATE are meant to ensure that there
is a unique correspondence between source tuples and result tuples,
which an output SRF destroys as much as anything else does.
2009-10-26 03:26:45 +01:00
|
|
|
|
2011-01-13 02:47:02 +01:00
|
|
|
subplan = mtstate->mt_plans[i]->plan;
|
|
|
|
aerm = ExecBuildAuxRowMark(erm, subplan->targetlist);
|
|
|
|
mtstate->mt_arowmarks[i] = lappend(mtstate->mt_arowmarks[i], aerm);
|
|
|
|
}
|
Re-implement EvalPlanQual processing to improve its performance and eliminate
a lot of strange behaviors that occurred in join cases. We now identify the
"current" row for every joined relation in UPDATE, DELETE, and SELECT FOR
UPDATE/SHARE queries. If an EvalPlanQual recheck is necessary, we jam the
appropriate row into each scan node in the rechecking plan, forcing it to emit
only that one row. The former behavior could rescan the whole of each joined
relation for each recheck, which was terrible for performance, and what's much
worse could result in duplicated output tuples.
Also, the original implementation of EvalPlanQual could not re-use the recheck
execution tree --- it had to go through a full executor init and shutdown for
every row to be tested. To avoid this overhead, I've associated a special
runtime Param with each LockRows or ModifyTable plan node, and arranged to
make every scan node below such a node depend on that Param. Thus, by
signaling a change in that Param, the EPQ machinery can just rescan the
already-built test plan.
This patch also adds a prohibition on set-returning functions in the
targetlist of SELECT FOR UPDATE/SHARE. This is needed to avoid the
duplicate-output-tuple problem. It seems fairly reasonable since the
other restrictions on SELECT FOR UPDATE are meant to ensure that there
is a unique correspondence between source tuples and result tuples,
which an output SRF destroys as much as anything else does.
2009-10-26 03:26:45 +01:00
|
|
|
}
|
|
|
|
|
2011-01-13 02:47:02 +01:00
|
|
|
/* select first subplan */
|
|
|
|
mtstate->mt_whichplan = 0;
|
|
|
|
subplan = (Plan *) linitial(node->plans);
|
|
|
|
EvalPlanQualSetPlan(&mtstate->mt_epqstate, subplan,
|
|
|
|
mtstate->mt_arowmarks[0]);
|
|
|
|
|
2009-10-10 03:43:50 +02:00
|
|
|
/*
|
|
|
|
* Initialize the junk filter(s) if needed. INSERT queries need a filter
|
2010-02-26 03:01:40 +01:00
|
|
|
* if there are any junk attrs in the tlist. UPDATE and DELETE always
|
2017-08-03 18:47:00 +02:00
|
|
|
* need a filter, since there's always at least one junk attribute present
|
|
|
|
* --- no need to look first. Typically, this will be a 'ctid' or
|
|
|
|
* 'wholerow' attribute, but in the case of a foreign data wrapper it
|
|
|
|
* might be a set of junk attributes sufficient to identify the remote
|
|
|
|
* row.
|
2009-10-10 03:43:50 +02:00
|
|
|
*
|
|
|
|
* If there are multiple result relations, each one needs its own junk
|
2014-05-06 18:12:18 +02:00
|
|
|
* filter. Note multiple rels are only possible for UPDATE/DELETE, so we
|
2009-10-10 03:43:50 +02:00
|
|
|
* can't be fooled by some needing a filter and some not.
|
|
|
|
*
|
|
|
|
* This section of code is also a convenient place to verify that the
|
|
|
|
* output of an INSERT or UPDATE matches the target table(s).
|
|
|
|
*/
|
|
|
|
{
|
|
|
|
bool junk_filter_needed = false;
|
|
|
|
|
|
|
|
switch (operation)
|
|
|
|
{
|
|
|
|
case CMD_INSERT:
|
|
|
|
foreach(l, subplan->targetlist)
|
|
|
|
{
|
|
|
|
TargetEntry *tle = (TargetEntry *) lfirst(l);
|
|
|
|
|
|
|
|
if (tle->resjunk)
|
|
|
|
{
|
|
|
|
junk_filter_needed = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case CMD_UPDATE:
|
|
|
|
case CMD_DELETE:
|
|
|
|
junk_filter_needed = true;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
elog(ERROR, "unknown operation");
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (junk_filter_needed)
|
|
|
|
{
|
2011-02-26 00:56:23 +01:00
|
|
|
resultRelInfo = mtstate->resultRelInfo;
|
2009-10-10 03:43:50 +02:00
|
|
|
for (i = 0; i < nplans; i++)
|
|
|
|
{
|
|
|
|
JunkFilter *j;
|
|
|
|
|
|
|
|
subplan = mtstate->mt_plans[i]->plan;
|
|
|
|
if (operation == CMD_INSERT || operation == CMD_UPDATE)
|
|
|
|
ExecCheckPlanOutput(resultRelInfo->ri_RelationDesc,
|
|
|
|
subplan->targetlist);
|
|
|
|
|
|
|
|
j = ExecInitJunkFilter(subplan->targetlist,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
resultRelInfo->ri_RelationDesc->rd_att->tdhasoid,
|
2009-10-10 03:43:50 +02:00
|
|
|
ExecInitExtraTupleSlot(estate));
|
|
|
|
|
|
|
|
if (operation == CMD_UPDATE || operation == CMD_DELETE)
|
|
|
|
{
|
2010-10-10 19:43:33 +02:00
|
|
|
/* For UPDATE/DELETE, find the appropriate junk attr now */
|
2013-03-10 19:14:53 +01:00
|
|
|
char relkind;
|
|
|
|
|
|
|
|
relkind = resultRelInfo->ri_RelationDesc->rd_rel->relkind;
|
2013-07-16 19:55:44 +02:00
|
|
|
if (relkind == RELKIND_RELATION ||
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
relkind == RELKIND_MATVIEW ||
|
|
|
|
relkind == RELKIND_PARTITIONED_TABLE)
|
2010-10-10 19:43:33 +02:00
|
|
|
{
|
|
|
|
j->jf_junkAttNo = ExecFindJunkAttribute(j, "ctid");
|
|
|
|
if (!AttributeNumberIsValid(j->jf_junkAttNo))
|
|
|
|
elog(ERROR, "could not find junk ctid column");
|
|
|
|
}
|
2013-03-10 19:14:53 +01:00
|
|
|
else if (relkind == RELKIND_FOREIGN_TABLE)
|
|
|
|
{
|
2014-03-23 07:16:34 +01:00
|
|
|
/*
|
2017-08-14 23:29:33 +02:00
|
|
|
* When there is a row-level trigger, there should be
|
|
|
|
* a wholerow attribute.
|
2014-03-23 07:16:34 +01:00
|
|
|
*/
|
|
|
|
j->jf_junkAttNo = ExecFindJunkAttribute(j, "wholerow");
|
2013-03-10 19:14:53 +01:00
|
|
|
}
|
2010-10-10 19:43:33 +02:00
|
|
|
else
|
|
|
|
{
|
|
|
|
j->jf_junkAttNo = ExecFindJunkAttribute(j, "wholerow");
|
|
|
|
if (!AttributeNumberIsValid(j->jf_junkAttNo))
|
|
|
|
elog(ERROR, "could not find junk wholerow column");
|
|
|
|
}
|
2009-10-10 03:43:50 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
resultRelInfo->ri_junkFilter = j;
|
|
|
|
resultRelInfo++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
if (operation == CMD_INSERT)
|
2011-02-26 00:56:23 +01:00
|
|
|
ExecCheckPlanOutput(mtstate->resultRelInfo->ri_RelationDesc,
|
2009-10-10 03:43:50 +02:00
|
|
|
subplan->targetlist);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2010-02-26 03:01:40 +01:00
|
|
|
* Set up a tuple table slot for use for trigger output tuples. In a plan
|
|
|
|
* containing multiple ModifyTable nodes, all can share one such slot, so
|
|
|
|
* we keep it in the estate.
|
2009-10-10 03:43:50 +02:00
|
|
|
*/
|
|
|
|
if (estate->es_trig_tuple_slot == NULL)
|
|
|
|
estate->es_trig_tuple_slot = ExecInitExtraTupleSlot(estate);
|
|
|
|
|
2011-02-26 00:56:23 +01:00
|
|
|
/*
|
|
|
|
* Lastly, if this is not the primary (canSetTag) ModifyTable node, add it
|
|
|
|
* to estate->es_auxmodifytables so that it will be run to completion by
|
|
|
|
* ExecPostprocessPlan. (It'd actually work fine to add the primary
|
2011-04-10 17:42:00 +02:00
|
|
|
* ModifyTable node too, but there's no need.) Note the use of lcons not
|
|
|
|
* lappend: we need later-initialized ModifyTable nodes to be shut down
|
|
|
|
* before earlier ones. This ensures that we don't throw away RETURNING
|
|
|
|
* rows that need to be seen by a later CTE subplan.
|
2011-02-26 00:56:23 +01:00
|
|
|
*/
|
|
|
|
if (!mtstate->canSetTag)
|
2011-02-26 05:53:34 +01:00
|
|
|
estate->es_auxmodifytables = lcons(mtstate,
|
|
|
|
estate->es_auxmodifytables);
|
2011-02-26 00:56:23 +01:00
|
|
|
|
2009-10-10 03:43:50 +02:00
|
|
|
return mtstate;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* ----------------------------------------------------------------
|
|
|
|
* ExecEndModifyTable
|
|
|
|
*
|
|
|
|
* Shuts down the plan.
|
|
|
|
*
|
|
|
|
* Returns nothing of interest.
|
|
|
|
* ----------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
ExecEndModifyTable(ModifyTableState *node)
|
|
|
|
{
|
2010-02-26 03:01:40 +01:00
|
|
|
int i;
|
2009-10-10 03:43:50 +02:00
|
|
|
|
2017-06-28 19:59:01 +02:00
|
|
|
/* Free transition tables */
|
|
|
|
if (node->mt_transition_capture != NULL)
|
|
|
|
DestroyTransitionCaptureState(node->mt_transition_capture);
|
|
|
|
|
2013-03-10 19:14:53 +01:00
|
|
|
/*
|
|
|
|
* Allow any FDWs to shut down
|
|
|
|
*/
|
|
|
|
for (i = 0; i < node->mt_nplans; i++)
|
|
|
|
{
|
|
|
|
ResultRelInfo *resultRelInfo = node->resultRelInfo + i;
|
|
|
|
|
2016-03-18 18:48:58 +01:00
|
|
|
if (!resultRelInfo->ri_usesFdwDirectModify &&
|
|
|
|
resultRelInfo->ri_FdwRoutine != NULL &&
|
2013-03-10 19:14:53 +01:00
|
|
|
resultRelInfo->ri_FdwRoutine->EndForeignModify != NULL)
|
|
|
|
resultRelInfo->ri_FdwRoutine->EndForeignModify(node->ps.state,
|
|
|
|
resultRelInfo);
|
|
|
|
}
|
|
|
|
|
2017-01-24 16:20:02 +01:00
|
|
|
/*
|
|
|
|
* Close all the partitioned tables, leaf partitions, and their indices
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
*
|
|
|
|
* Remember node->mt_partition_dispatch_info[0] corresponds to the root
|
|
|
|
* partitioned table, which we must not try to close, because it is the
|
|
|
|
* main target table of the query that will be closed by ExecEndPlan().
|
2016-12-22 23:31:52 +01:00
|
|
|
* Also, tupslot is NULL for the root partitioned table.
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
*/
|
|
|
|
for (i = 1; i < node->mt_num_dispatch; i++)
|
|
|
|
{
|
|
|
|
PartitionDispatch pd = node->mt_partition_dispatch_info[i];
|
|
|
|
|
|
|
|
heap_close(pd->reldesc, NoLock);
|
2016-12-22 23:31:52 +01:00
|
|
|
ExecDropSingleTupleTableSlot(pd->tupslot);
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
}
|
|
|
|
for (i = 0; i < node->mt_num_partitions; i++)
|
|
|
|
{
|
|
|
|
ResultRelInfo *resultRelInfo = node->mt_partitions + i;
|
|
|
|
|
|
|
|
ExecCloseIndices(resultRelInfo);
|
|
|
|
heap_close(resultRelInfo->ri_RelationDesc, NoLock);
|
|
|
|
}
|
|
|
|
|
2017-01-04 19:05:29 +01:00
|
|
|
/* Release the standalone partition tuple descriptor, if any */
|
|
|
|
if (node->mt_partition_tuple_slot)
|
|
|
|
ExecDropSingleTupleTableSlot(node->mt_partition_tuple_slot);
|
|
|
|
|
2009-10-10 03:43:50 +02:00
|
|
|
/*
|
|
|
|
* Free the exprcontext
|
|
|
|
*/
|
|
|
|
ExecFreeExprContext(&node->ps);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* clean out the tuple table
|
|
|
|
*/
|
|
|
|
ExecClearTuple(node->ps.ps_ResultTupleSlot);
|
|
|
|
|
Re-implement EvalPlanQual processing to improve its performance and eliminate
a lot of strange behaviors that occurred in join cases. We now identify the
"current" row for every joined relation in UPDATE, DELETE, and SELECT FOR
UPDATE/SHARE queries. If an EvalPlanQual recheck is necessary, we jam the
appropriate row into each scan node in the rechecking plan, forcing it to emit
only that one row. The former behavior could rescan the whole of each joined
relation for each recheck, which was terrible for performance, and what's much
worse could result in duplicated output tuples.
Also, the original implementation of EvalPlanQual could not re-use the recheck
execution tree --- it had to go through a full executor init and shutdown for
every row to be tested. To avoid this overhead, I've associated a special
runtime Param with each LockRows or ModifyTable plan node, and arranged to
make every scan node below such a node depend on that Param. Thus, by
signaling a change in that Param, the EPQ machinery can just rescan the
already-built test plan.
This patch also adds a prohibition on set-returning functions in the
targetlist of SELECT FOR UPDATE/SHARE. This is needed to avoid the
duplicate-output-tuple problem. It seems fairly reasonable since the
other restrictions on SELECT FOR UPDATE are meant to ensure that there
is a unique correspondence between source tuples and result tuples,
which an output SRF destroys as much as anything else does.
2009-10-26 03:26:45 +01:00
|
|
|
/*
|
|
|
|
* Terminate EPQ execution if active
|
|
|
|
*/
|
|
|
|
EvalPlanQualEnd(&node->mt_epqstate);
|
|
|
|
|
2009-10-10 03:43:50 +02:00
|
|
|
/*
|
|
|
|
* shut down subplans
|
|
|
|
*/
|
2010-02-26 03:01:40 +01:00
|
|
|
for (i = 0; i < node->mt_nplans; i++)
|
2009-10-10 03:43:50 +02:00
|
|
|
ExecEndNode(node->mt_plans[i]);
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
2010-07-12 19:01:06 +02:00
|
|
|
ExecReScanModifyTable(ModifyTableState *node)
|
2009-10-10 03:43:50 +02:00
|
|
|
{
|
|
|
|
/*
|
2010-02-26 03:01:40 +01:00
|
|
|
* Currently, we don't need to support rescan on ModifyTable nodes. The
|
|
|
|
* semantics of that would be a bit debatable anyway.
|
2009-10-10 03:43:50 +02:00
|
|
|
*/
|
|
|
|
elog(ERROR, "ExecReScanModifyTable is not implemented");
|
|
|
|
}
|