2007-06-11 03:16:30 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* execCurrent.c
|
|
|
|
* executor support for WHERE CURRENT OF cursor
|
|
|
|
*
|
2018-01-03 05:30:12 +01:00
|
|
|
* Portions Copyright (c) 1996-2018, PostgreSQL Global Development Group
|
2007-06-11 03:16:30 +02:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/backend/executor/execCurrent.c
|
2007-06-11 03:16:30 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#include "postgres.h"
|
|
|
|
|
2018-03-17 19:59:31 +01:00
|
|
|
#include "access/relscan.h"
|
2008-05-12 02:00:54 +02:00
|
|
|
#include "access/sysattr.h"
|
2007-06-12 00:22:42 +02:00
|
|
|
#include "catalog/pg_type.h"
|
2007-06-11 03:16:30 +02:00
|
|
|
#include "executor/executor.h"
|
2007-06-12 00:22:42 +02:00
|
|
|
#include "utils/builtins.h"
|
2007-06-11 03:16:30 +02:00
|
|
|
#include "utils/lsyscache.h"
|
|
|
|
#include "utils/portal.h"
|
2011-02-23 18:18:09 +01:00
|
|
|
#include "utils/rel.h"
|
2007-06-11 03:16:30 +02:00
|
|
|
|
|
|
|
|
2009-11-09 03:36:59 +01:00
|
|
|
static char *fetch_cursor_param_value(ExprContext *econtext, int paramId);
|
Fix failure in WHERE CURRENT OF after rewinding the referenced cursor.
In a case where we have multiple relation-scan nodes in a cursor plan,
such as a scan of an inheritance tree, it's possible to fetch from a
given scan node, then rewind the cursor and fetch some row from an
earlier scan node. In such a case, execCurrent.c mistakenly thought
that the later scan node was still active, because ExecReScan hadn't
done anything to make it look not-active. We'd get some sort of
failure in the case of a SeqScan node, because the node's scan tuple
slot would be pointing at a HeapTuple whose t_self gets reset to
invalid by heapam.c. But it seems possible that for other relation
scan node types we'd actually return a valid tuple TID to the caller,
resulting in updating or deleting a tuple that shouldn't have been
considered current. To fix, forcibly clear the ScanTupleSlot in
ExecScanReScan.
Another issue here, which seems only latent at the moment but could
easily become a live bug in future, is that rewinding a cursor does
not necessarily lead to *immediately* applying ExecReScan to every
scan-level node in the plan tree. Upper-level nodes will think that
they can postpone that call if their child node is already marked
with chgParam flags. I don't see a way for that to happen today in
a plan tree that's simple enough for execCurrent.c's search_plan_tree
to understand, but that's one heck of a fragile assumption. So, add
some logic in search_plan_tree to detect chgParam flags being set on
nodes that it descended to/through, and assume that that means we
should consider lower scan nodes to be logically reset even if their
ReScan call hasn't actually happened yet.
Per bug #15395 from Matvey Arye. This has been broken for a long time,
so back-patch to all supported branches.
Discussion: https://postgr.es/m/153764171023.14986.280404050547008575@wrigleys.postgresql.org
2018-09-23 22:05:45 +02:00
|
|
|
static ScanState *search_plan_tree(PlanState *node, Oid table_oid,
|
|
|
|
bool *pending_rescan);
|
2007-06-11 03:16:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* execCurrentOf
|
|
|
|
*
|
2007-06-12 00:22:42 +02:00
|
|
|
* Given a CURRENT OF expression and the OID of a table, determine which row
|
|
|
|
* of the table is currently being scanned by the cursor named by CURRENT OF,
|
|
|
|
* and return the row's TID into *current_tid.
|
2007-06-11 03:16:30 +02:00
|
|
|
*
|
2017-08-16 06:22:32 +02:00
|
|
|
* Returns true if a row was identified. Returns false if the cursor is valid
|
2007-06-11 03:16:30 +02:00
|
|
|
* for the table but is not currently scanning a row of the table (this is a
|
|
|
|
* legal situation in inheritance cases). Raises error if cursor is not a
|
|
|
|
* valid updatable scan of the specified table.
|
|
|
|
*/
|
|
|
|
bool
|
2007-11-15 23:25:18 +01:00
|
|
|
execCurrentOf(CurrentOfExpr *cexpr,
|
2007-06-12 00:22:42 +02:00
|
|
|
ExprContext *econtext,
|
|
|
|
Oid table_oid,
|
2007-06-11 03:16:30 +02:00
|
|
|
ItemPointer current_tid)
|
|
|
|
{
|
2007-06-12 00:22:42 +02:00
|
|
|
char *cursor_name;
|
2007-06-11 03:16:30 +02:00
|
|
|
char *table_name;
|
|
|
|
Portal portal;
|
2007-11-15 22:14:46 +01:00
|
|
|
QueryDesc *queryDesc;
|
2007-06-12 00:22:42 +02:00
|
|
|
|
|
|
|
/* Get the cursor name --- may have to look up a parameter reference */
|
|
|
|
if (cexpr->cursor_name)
|
|
|
|
cursor_name = cexpr->cursor_name;
|
|
|
|
else
|
2009-11-09 03:36:59 +01:00
|
|
|
cursor_name = fetch_cursor_param_value(econtext, cexpr->cursor_param);
|
2007-06-11 03:16:30 +02:00
|
|
|
|
|
|
|
/* Fetch table name for possible use in error messages */
|
|
|
|
table_name = get_rel_name(table_oid);
|
|
|
|
if (table_name == NULL)
|
|
|
|
elog(ERROR, "cache lookup failed for relation %u", table_oid);
|
|
|
|
|
|
|
|
/* Find the cursor's portal */
|
|
|
|
portal = GetPortalByName(cursor_name);
|
|
|
|
if (!PortalIsValid(portal))
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_UNDEFINED_CURSOR),
|
|
|
|
errmsg("cursor \"%s\" does not exist", cursor_name)));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We have to watch out for non-SELECT queries as well as held cursors,
|
|
|
|
* both of which may have null queryDesc.
|
|
|
|
*/
|
|
|
|
if (portal->strategy != PORTAL_ONE_SELECT)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_CURSOR_STATE),
|
|
|
|
errmsg("cursor \"%s\" is not a SELECT query",
|
|
|
|
cursor_name)));
|
2017-12-16 23:43:41 +01:00
|
|
|
queryDesc = portal->queryDesc;
|
2008-11-16 18:34:28 +01:00
|
|
|
if (queryDesc == NULL || queryDesc->estate == NULL)
|
2007-06-11 03:16:30 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_CURSOR_STATE),
|
|
|
|
errmsg("cursor \"%s\" is held from a previous transaction",
|
|
|
|
cursor_name)));
|
|
|
|
|
|
|
|
/*
|
2008-11-16 18:34:28 +01:00
|
|
|
* We have two different strategies depending on whether the cursor uses
|
|
|
|
* FOR UPDATE/SHARE or not. The reason for supporting both is that the
|
|
|
|
* FOR UPDATE code is able to identify a target table in many cases where
|
|
|
|
* the other code can't, while the non-FOR-UPDATE case allows use of WHERE
|
|
|
|
* CURRENT OF with an insensitive cursor.
|
2007-06-11 03:16:30 +02:00
|
|
|
*/
|
2018-10-08 16:41:34 +02:00
|
|
|
if (queryDesc->estate->es_rowmarks)
|
2008-11-16 18:34:28 +01:00
|
|
|
{
|
|
|
|
ExecRowMark *erm;
|
2018-10-08 16:41:34 +02:00
|
|
|
Index i;
|
2008-11-16 18:34:28 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Here, the query must have exactly one FOR UPDATE/SHARE reference to
|
|
|
|
* the target table, and we dig the ctid info out of that.
|
|
|
|
*/
|
|
|
|
erm = NULL;
|
2018-10-08 16:41:34 +02:00
|
|
|
for (i = 0; i < queryDesc->estate->es_range_table_size; i++)
|
2008-11-16 18:34:28 +01:00
|
|
|
{
|
2018-10-08 16:41:34 +02:00
|
|
|
ExecRowMark *thiserm = queryDesc->estate->es_rowmarks[i];
|
2008-11-16 18:34:28 +01:00
|
|
|
|
2018-10-08 16:41:34 +02:00
|
|
|
if (thiserm == NULL ||
|
|
|
|
!RowMarkRequiresRowShareLock(thiserm->markType))
|
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
|
|
|
continue; /* ignore non-FOR UPDATE/SHARE items */
|
|
|
|
|
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
|
|
|
if (thiserm->relid == table_oid)
|
2008-11-16 18:34:28 +01:00
|
|
|
{
|
|
|
|
if (erm)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_CURSOR_STATE),
|
|
|
|
errmsg("cursor \"%s\" has multiple FOR UPDATE/SHARE references to table \"%s\"",
|
|
|
|
cursor_name, table_name)));
|
|
|
|
erm = thiserm;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (erm == NULL)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_CURSOR_STATE),
|
|
|
|
errmsg("cursor \"%s\" does not have a FOR UPDATE/SHARE reference to table \"%s\"",
|
|
|
|
cursor_name, table_name)));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The cursor must have a current result row: per the SQL spec, it's
|
|
|
|
* an error if not.
|
|
|
|
*/
|
|
|
|
if (portal->atStart || portal->atEnd)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_CURSOR_STATE),
|
|
|
|
errmsg("cursor \"%s\" is not positioned on a row",
|
|
|
|
cursor_name)));
|
|
|
|
|
|
|
|
/* Return the currently scanned TID, if there is one */
|
|
|
|
if (ItemPointerIsValid(&(erm->curCtid)))
|
|
|
|
{
|
|
|
|
*current_tid = erm->curCtid;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This table didn't produce the cursor's current row; some other
|
2014-05-06 18:12:18 +02:00
|
|
|
* inheritance child of the same parent must have. Signal caller to
|
2009-06-11 16:49:15 +02:00
|
|
|
* do nothing on this table.
|
2008-11-16 18:34:28 +01:00
|
|
|
*/
|
2007-06-11 03:16:30 +02:00
|
|
|
return false;
|
2008-11-16 18:34:28 +01:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Without FOR UPDATE, we dig through the cursor's plan to find the
|
|
|
|
* scan node. Fail if it's not there or buried underneath
|
|
|
|
* aggregation.
|
|
|
|
*/
|
2018-03-17 19:59:31 +01:00
|
|
|
ScanState *scanstate;
|
Fix failure in WHERE CURRENT OF after rewinding the referenced cursor.
In a case where we have multiple relation-scan nodes in a cursor plan,
such as a scan of an inheritance tree, it's possible to fetch from a
given scan node, then rewind the cursor and fetch some row from an
earlier scan node. In such a case, execCurrent.c mistakenly thought
that the later scan node was still active, because ExecReScan hadn't
done anything to make it look not-active. We'd get some sort of
failure in the case of a SeqScan node, because the node's scan tuple
slot would be pointing at a HeapTuple whose t_self gets reset to
invalid by heapam.c. But it seems possible that for other relation
scan node types we'd actually return a valid tuple TID to the caller,
resulting in updating or deleting a tuple that shouldn't have been
considered current. To fix, forcibly clear the ScanTupleSlot in
ExecScanReScan.
Another issue here, which seems only latent at the moment but could
easily become a live bug in future, is that rewinding a cursor does
not necessarily lead to *immediately* applying ExecReScan to every
scan-level node in the plan tree. Upper-level nodes will think that
they can postpone that call if their child node is already marked
with chgParam flags. I don't see a way for that to happen today in
a plan tree that's simple enough for execCurrent.c's search_plan_tree
to understand, but that's one heck of a fragile assumption. So, add
some logic in search_plan_tree to detect chgParam flags being set on
nodes that it descended to/through, and assume that that means we
should consider lower scan nodes to be logically reset even if their
ReScan call hasn't actually happened yet.
Per bug #15395 from Matvey Arye. This has been broken for a long time,
so back-patch to all supported branches.
Discussion: https://postgr.es/m/153764171023.14986.280404050547008575@wrigleys.postgresql.org
2018-09-23 22:05:45 +02:00
|
|
|
bool pending_rescan = false;
|
2018-03-17 19:59:31 +01:00
|
|
|
|
Fix failure in WHERE CURRENT OF after rewinding the referenced cursor.
In a case where we have multiple relation-scan nodes in a cursor plan,
such as a scan of an inheritance tree, it's possible to fetch from a
given scan node, then rewind the cursor and fetch some row from an
earlier scan node. In such a case, execCurrent.c mistakenly thought
that the later scan node was still active, because ExecReScan hadn't
done anything to make it look not-active. We'd get some sort of
failure in the case of a SeqScan node, because the node's scan tuple
slot would be pointing at a HeapTuple whose t_self gets reset to
invalid by heapam.c. But it seems possible that for other relation
scan node types we'd actually return a valid tuple TID to the caller,
resulting in updating or deleting a tuple that shouldn't have been
considered current. To fix, forcibly clear the ScanTupleSlot in
ExecScanReScan.
Another issue here, which seems only latent at the moment but could
easily become a live bug in future, is that rewinding a cursor does
not necessarily lead to *immediately* applying ExecReScan to every
scan-level node in the plan tree. Upper-level nodes will think that
they can postpone that call if their child node is already marked
with chgParam flags. I don't see a way for that to happen today in
a plan tree that's simple enough for execCurrent.c's search_plan_tree
to understand, but that's one heck of a fragile assumption. So, add
some logic in search_plan_tree to detect chgParam flags being set on
nodes that it descended to/through, and assume that that means we
should consider lower scan nodes to be logically reset even if their
ReScan call hasn't actually happened yet.
Per bug #15395 from Matvey Arye. This has been broken for a long time,
so back-patch to all supported branches.
Discussion: https://postgr.es/m/153764171023.14986.280404050547008575@wrigleys.postgresql.org
2018-09-23 22:05:45 +02:00
|
|
|
scanstate = search_plan_tree(queryDesc->planstate, table_oid,
|
|
|
|
&pending_rescan);
|
2008-11-16 18:34:28 +01:00
|
|
|
if (!scanstate)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_CURSOR_STATE),
|
|
|
|
errmsg("cursor \"%s\" is not a simply updatable scan of table \"%s\"",
|
|
|
|
cursor_name, table_name)));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The cursor must have a current result row: per the SQL spec, it's
|
|
|
|
* an error if not. We test this at the top level, rather than at the
|
|
|
|
* scan node level, because in inheritance cases any one table scan
|
|
|
|
* could easily not be on a row. We want to return false, not raise
|
|
|
|
* error, if the passed-in table OID is for one of the inactive scans.
|
|
|
|
*/
|
|
|
|
if (portal->atStart || portal->atEnd)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_CURSOR_STATE),
|
|
|
|
errmsg("cursor \"%s\" is not positioned on a row",
|
|
|
|
cursor_name)));
|
|
|
|
|
Fix failure in WHERE CURRENT OF after rewinding the referenced cursor.
In a case where we have multiple relation-scan nodes in a cursor plan,
such as a scan of an inheritance tree, it's possible to fetch from a
given scan node, then rewind the cursor and fetch some row from an
earlier scan node. In such a case, execCurrent.c mistakenly thought
that the later scan node was still active, because ExecReScan hadn't
done anything to make it look not-active. We'd get some sort of
failure in the case of a SeqScan node, because the node's scan tuple
slot would be pointing at a HeapTuple whose t_self gets reset to
invalid by heapam.c. But it seems possible that for other relation
scan node types we'd actually return a valid tuple TID to the caller,
resulting in updating or deleting a tuple that shouldn't have been
considered current. To fix, forcibly clear the ScanTupleSlot in
ExecScanReScan.
Another issue here, which seems only latent at the moment but could
easily become a live bug in future, is that rewinding a cursor does
not necessarily lead to *immediately* applying ExecReScan to every
scan-level node in the plan tree. Upper-level nodes will think that
they can postpone that call if their child node is already marked
with chgParam flags. I don't see a way for that to happen today in
a plan tree that's simple enough for execCurrent.c's search_plan_tree
to understand, but that's one heck of a fragile assumption. So, add
some logic in search_plan_tree to detect chgParam flags being set on
nodes that it descended to/through, and assume that that means we
should consider lower scan nodes to be logically reset even if their
ReScan call hasn't actually happened yet.
Per bug #15395 from Matvey Arye. This has been broken for a long time,
so back-patch to all supported branches.
Discussion: https://postgr.es/m/153764171023.14986.280404050547008575@wrigleys.postgresql.org
2018-09-23 22:05:45 +02:00
|
|
|
/*
|
|
|
|
* Now OK to return false if we found an inactive scan. It is
|
|
|
|
* inactive either if it's not positioned on a row, or there's a
|
|
|
|
* rescan pending for it.
|
|
|
|
*/
|
|
|
|
if (TupIsNull(scanstate->ss_ScanTupleSlot) || pending_rescan)
|
2008-11-16 18:34:28 +01:00
|
|
|
return false;
|
|
|
|
|
2018-03-17 19:59:31 +01:00
|
|
|
/*
|
|
|
|
* Extract TID of the scan's current row. The mechanism for this is
|
|
|
|
* in principle scan-type-dependent, but for most scan types, we can
|
|
|
|
* just dig the TID out of the physical scan tuple.
|
|
|
|
*/
|
|
|
|
if (IsA(scanstate, IndexOnlyScanState))
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* For IndexOnlyScan, the tuple stored in ss_ScanTupleSlot may be
|
|
|
|
* a virtual tuple that does not have the ctid column, so we have
|
|
|
|
* to get the TID from xs_ctup.t_self.
|
|
|
|
*/
|
|
|
|
IndexScanDesc scan = ((IndexOnlyScanState *) scanstate)->ioss_ScanDesc;
|
|
|
|
|
|
|
|
*current_tid = scan->xs_ctup.t_self;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Default case: try to fetch TID from the scan node's current
|
|
|
|
* tuple. As an extra cross-check, verify tableoid in the current
|
|
|
|
* tuple. If the scan hasn't provided a physical tuple, we have
|
|
|
|
* to fail.
|
|
|
|
*/
|
|
|
|
Datum ldatum;
|
|
|
|
bool lisnull;
|
|
|
|
ItemPointer tuple_tid;
|
|
|
|
|
|
|
|
#ifdef USE_ASSERT_CHECKING
|
Make TupleTableSlots extensible, finish split of existing slot type.
This commit completes the work prepared in 1a0586de36, splitting the
old TupleTableSlot implementation (which could store buffer, heap,
minimal and virtual slots) into four different slot types. As
described in the aforementioned commit, this is done with the goal of
making tuple table slots extensible, to allow for pluggable table
access methods.
To achieve runtime extensibility for TupleTableSlots, operations on
slots that can differ between types of slots are performed using the
TupleTableSlotOps struct provided at slot creation time. That
includes information from the size of TupleTableSlot struct to be
allocated, initialization, deforming etc. See the struct's definition
for more detailed information about callbacks TupleTableSlotOps.
I decided to rename TTSOpsBufferTuple to TTSOpsBufferHeapTuple and
ExecCopySlotTuple to ExecCopySlotHeapTuple, as that seems more
consistent with other naming introduced in recent patches.
There's plenty optimization potential in the slot implementation, but
according to benchmarking the state after this commit has similar
performance characteristics to before this set of changes, which seems
sufficient.
There's a few changes in execReplication.c that currently need to poke
through the slot abstraction, that'll be repaired once the pluggable
storage patchset provides the necessary infrastructure.
Author: Andres Freund and Ashutosh Bapat, with changes by Amit Khandekar
Discussion: https://postgr.es/m/20181105210039.hh4vvi4vwoq5ba2q@alap3.anarazel.de
2018-11-17 01:35:11 +01:00
|
|
|
ldatum = slot_getsysattr(scanstate->ss_ScanTupleSlot,
|
|
|
|
TableOidAttributeNumber,
|
|
|
|
&lisnull);
|
|
|
|
if (lisnull)
|
2018-03-17 19:59:31 +01:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_CURSOR_STATE),
|
|
|
|
errmsg("cursor \"%s\" is not a simply updatable scan of table \"%s\"",
|
|
|
|
cursor_name, table_name)));
|
|
|
|
Assert(DatumGetObjectId(ldatum) == table_oid);
|
|
|
|
#endif
|
|
|
|
|
Make TupleTableSlots extensible, finish split of existing slot type.
This commit completes the work prepared in 1a0586de36, splitting the
old TupleTableSlot implementation (which could store buffer, heap,
minimal and virtual slots) into four different slot types. As
described in the aforementioned commit, this is done with the goal of
making tuple table slots extensible, to allow for pluggable table
access methods.
To achieve runtime extensibility for TupleTableSlots, operations on
slots that can differ between types of slots are performed using the
TupleTableSlotOps struct provided at slot creation time. That
includes information from the size of TupleTableSlot struct to be
allocated, initialization, deforming etc. See the struct's definition
for more detailed information about callbacks TupleTableSlotOps.
I decided to rename TTSOpsBufferTuple to TTSOpsBufferHeapTuple and
ExecCopySlotTuple to ExecCopySlotHeapTuple, as that seems more
consistent with other naming introduced in recent patches.
There's plenty optimization potential in the slot implementation, but
according to benchmarking the state after this commit has similar
performance characteristics to before this set of changes, which seems
sufficient.
There's a few changes in execReplication.c that currently need to poke
through the slot abstraction, that'll be repaired once the pluggable
storage patchset provides the necessary infrastructure.
Author: Andres Freund and Ashutosh Bapat, with changes by Amit Khandekar
Discussion: https://postgr.es/m/20181105210039.hh4vvi4vwoq5ba2q@alap3.anarazel.de
2018-11-17 01:35:11 +01:00
|
|
|
ldatum = slot_getsysattr(scanstate->ss_ScanTupleSlot,
|
|
|
|
SelfItemPointerAttributeNumber,
|
|
|
|
&lisnull);
|
|
|
|
if (lisnull)
|
2018-03-17 19:59:31 +01:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_CURSOR_STATE),
|
|
|
|
errmsg("cursor \"%s\" is not a simply updatable scan of table \"%s\"",
|
|
|
|
cursor_name, table_name)));
|
|
|
|
tuple_tid = (ItemPointer) DatumGetPointer(ldatum);
|
|
|
|
|
|
|
|
*current_tid = *tuple_tid;
|
|
|
|
}
|
|
|
|
|
|
|
|
Assert(ItemPointerIsValid(current_tid));
|
2008-11-16 18:34:28 +01:00
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
2007-06-11 03:16:30 +02:00
|
|
|
}
|
|
|
|
|
2007-06-12 00:22:42 +02:00
|
|
|
/*
|
2009-11-09 03:36:59 +01:00
|
|
|
* fetch_cursor_param_value
|
2007-06-12 00:22:42 +02:00
|
|
|
*
|
|
|
|
* Fetch the string value of a param, verifying it is of type REFCURSOR.
|
|
|
|
*/
|
|
|
|
static char *
|
2009-11-09 03:36:59 +01:00
|
|
|
fetch_cursor_param_value(ExprContext *econtext, int paramId)
|
2007-06-12 00:22:42 +02:00
|
|
|
{
|
|
|
|
ParamListInfo paramInfo = econtext->ecxt_param_list_info;
|
|
|
|
|
|
|
|
if (paramInfo &&
|
|
|
|
paramId > 0 && paramId <= paramInfo->numParams)
|
|
|
|
{
|
Rearrange execution of PARAM_EXTERN Params for plpgsql's benefit.
This patch does three interrelated things:
* Create a new expression execution step type EEOP_PARAM_CALLBACK
and add the infrastructure needed for add-on modules to generate that.
As discussed, the best control mechanism for that seems to be to add
another hook function to ParamListInfo, which will be called by
ExecInitExpr if it's supplied and a PARAM_EXTERN Param is found.
For stand-alone expressions, we add a new entry point to allow the
ParamListInfo to be specified directly, since it can't be retrieved
from the parent plan node's EState.
* Redesign the API for the ParamListInfo paramFetch hook so that the
ParamExternData array can be entirely virtual. This also lets us get rid
of ParamListInfo.paramMask, instead leaving it to the paramFetch hook to
decide which param IDs should be accessible or not. plpgsql_param_fetch
was already doing the identical masking check, so having callers do it too
seemed redundant. While I was at it, I added a "speculative" flag to
paramFetch that the planner can specify as TRUE to avoid unwanted failures.
This solves an ancient problem for plpgsql that it couldn't provide values
of non-DTYPE_VAR variables to the planner for fear of triggering premature
"record not assigned yet" or "field not found" errors during planning.
* Rework plpgsql to get rid of the need for "unshared" parameter lists,
by dint of turning the single ParamListInfo per estate into a nearly
read-only data structure that doesn't instantiate any per-variable data.
Instead, the paramFetch hook controls access to per-variable data and can
make the right decisions on the fly, replacing the cases that we used to
need multiple ParamListInfos for. This might perhaps have been a
performance loss on its own, but by using a paramCompile hook we can
bypass plpgsql_param_fetch entirely during normal query execution.
(It's now only called when, eg, we copy the ParamListInfo into a cursor
portal. copyParamList() or SerializeParamList() effectively instantiate
the virtual parameter array as a simple physical array without a
paramFetch hook, which is what we want in those cases.) This allows
reverting most of commit 6c82d8d1f, though I kept the cosmetic
code-consolidation aspects of that (eg the assign_simple_var function).
Performance testing shows this to be at worst a break-even change,
and it can provide wins ranging up to 20% in test cases involving
accesses to fields of "record" variables. The fact that values of
such variables can now be exposed to the planner might produce wins
in some situations, too, but I've not pursued that angle.
In passing, remove the "parent" pointer from the arguments to
ExecInitExprRec and related functions, instead storing that pointer in a
transient field in ExprState. The ParamListInfo pointer for a stand-alone
expression is handled the same way; we'd otherwise have had to add
yet another recursively-passed-down argument in expression compilation.
Discussion: https://postgr.es/m/32589.1513706441@sss.pgh.pa.us
2017-12-21 18:57:41 +01:00
|
|
|
ParamExternData *prm;
|
|
|
|
ParamExternData prmdata;
|
2007-06-12 00:22:42 +02:00
|
|
|
|
2009-11-04 23:26:08 +01:00
|
|
|
/* give hook a chance in case parameter is dynamic */
|
Rearrange execution of PARAM_EXTERN Params for plpgsql's benefit.
This patch does three interrelated things:
* Create a new expression execution step type EEOP_PARAM_CALLBACK
and add the infrastructure needed for add-on modules to generate that.
As discussed, the best control mechanism for that seems to be to add
another hook function to ParamListInfo, which will be called by
ExecInitExpr if it's supplied and a PARAM_EXTERN Param is found.
For stand-alone expressions, we add a new entry point to allow the
ParamListInfo to be specified directly, since it can't be retrieved
from the parent plan node's EState.
* Redesign the API for the ParamListInfo paramFetch hook so that the
ParamExternData array can be entirely virtual. This also lets us get rid
of ParamListInfo.paramMask, instead leaving it to the paramFetch hook to
decide which param IDs should be accessible or not. plpgsql_param_fetch
was already doing the identical masking check, so having callers do it too
seemed redundant. While I was at it, I added a "speculative" flag to
paramFetch that the planner can specify as TRUE to avoid unwanted failures.
This solves an ancient problem for plpgsql that it couldn't provide values
of non-DTYPE_VAR variables to the planner for fear of triggering premature
"record not assigned yet" or "field not found" errors during planning.
* Rework plpgsql to get rid of the need for "unshared" parameter lists,
by dint of turning the single ParamListInfo per estate into a nearly
read-only data structure that doesn't instantiate any per-variable data.
Instead, the paramFetch hook controls access to per-variable data and can
make the right decisions on the fly, replacing the cases that we used to
need multiple ParamListInfos for. This might perhaps have been a
performance loss on its own, but by using a paramCompile hook we can
bypass plpgsql_param_fetch entirely during normal query execution.
(It's now only called when, eg, we copy the ParamListInfo into a cursor
portal. copyParamList() or SerializeParamList() effectively instantiate
the virtual parameter array as a simple physical array without a
paramFetch hook, which is what we want in those cases.) This allows
reverting most of commit 6c82d8d1f, though I kept the cosmetic
code-consolidation aspects of that (eg the assign_simple_var function).
Performance testing shows this to be at worst a break-even change,
and it can provide wins ranging up to 20% in test cases involving
accesses to fields of "record" variables. The fact that values of
such variables can now be exposed to the planner might produce wins
in some situations, too, but I've not pursued that angle.
In passing, remove the "parent" pointer from the arguments to
ExecInitExprRec and related functions, instead storing that pointer in a
transient field in ExprState. The ParamListInfo pointer for a stand-alone
expression is handled the same way; we'd otherwise have had to add
yet another recursively-passed-down argument in expression compilation.
Discussion: https://postgr.es/m/32589.1513706441@sss.pgh.pa.us
2017-12-21 18:57:41 +01:00
|
|
|
if (paramInfo->paramFetch != NULL)
|
|
|
|
prm = paramInfo->paramFetch(paramInfo, paramId, false, &prmdata);
|
|
|
|
else
|
|
|
|
prm = ¶mInfo->params[paramId - 1];
|
2009-11-04 23:26:08 +01:00
|
|
|
|
2007-06-12 00:22:42 +02:00
|
|
|
if (OidIsValid(prm->ptype) && !prm->isnull)
|
|
|
|
{
|
2009-11-04 23:26:08 +01:00
|
|
|
/* safety check in case hook did something unexpected */
|
|
|
|
if (prm->ptype != REFCURSOROID)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_DATATYPE_MISMATCH),
|
|
|
|
errmsg("type of parameter %d (%s) does not match that when preparing the plan (%s)",
|
|
|
|
paramId,
|
|
|
|
format_type_be(prm->ptype),
|
|
|
|
format_type_be(REFCURSOROID))));
|
|
|
|
|
2007-06-12 00:22:42 +02:00
|
|
|
/* We know that refcursor uses text's I/O routines */
|
2008-03-25 23:42:46 +01:00
|
|
|
return TextDatumGetCString(prm->value);
|
2007-06-12 00:22:42 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_UNDEFINED_OBJECT),
|
|
|
|
errmsg("no value found for parameter %d", paramId)));
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2007-06-11 03:16:30 +02:00
|
|
|
/*
|
|
|
|
* search_plan_tree
|
|
|
|
*
|
|
|
|
* Search through a PlanState tree for a scan node on the specified table.
|
|
|
|
* Return NULL if not found or multiple candidates.
|
Fix failure in WHERE CURRENT OF after rewinding the referenced cursor.
In a case where we have multiple relation-scan nodes in a cursor plan,
such as a scan of an inheritance tree, it's possible to fetch from a
given scan node, then rewind the cursor and fetch some row from an
earlier scan node. In such a case, execCurrent.c mistakenly thought
that the later scan node was still active, because ExecReScan hadn't
done anything to make it look not-active. We'd get some sort of
failure in the case of a SeqScan node, because the node's scan tuple
slot would be pointing at a HeapTuple whose t_self gets reset to
invalid by heapam.c. But it seems possible that for other relation
scan node types we'd actually return a valid tuple TID to the caller,
resulting in updating or deleting a tuple that shouldn't have been
considered current. To fix, forcibly clear the ScanTupleSlot in
ExecScanReScan.
Another issue here, which seems only latent at the moment but could
easily become a live bug in future, is that rewinding a cursor does
not necessarily lead to *immediately* applying ExecReScan to every
scan-level node in the plan tree. Upper-level nodes will think that
they can postpone that call if their child node is already marked
with chgParam flags. I don't see a way for that to happen today in
a plan tree that's simple enough for execCurrent.c's search_plan_tree
to understand, but that's one heck of a fragile assumption. So, add
some logic in search_plan_tree to detect chgParam flags being set on
nodes that it descended to/through, and assume that that means we
should consider lower scan nodes to be logically reset even if their
ReScan call hasn't actually happened yet.
Per bug #15395 from Matvey Arye. This has been broken for a long time,
so back-patch to all supported branches.
Discussion: https://postgr.es/m/153764171023.14986.280404050547008575@wrigleys.postgresql.org
2018-09-23 22:05:45 +02:00
|
|
|
*
|
|
|
|
* If a candidate is found, set *pending_rescan to true if that candidate
|
|
|
|
* or any node above it has a pending rescan action, i.e. chgParam != NULL.
|
|
|
|
* That indicates that we shouldn't consider the node to be positioned on a
|
|
|
|
* valid tuple, even if its own state would indicate that it is. (Caller
|
|
|
|
* must initialize *pending_rescan to false, and should not trust its state
|
|
|
|
* if multiple candidates are found.)
|
2007-06-11 03:16:30 +02:00
|
|
|
*/
|
|
|
|
static ScanState *
|
Fix failure in WHERE CURRENT OF after rewinding the referenced cursor.
In a case where we have multiple relation-scan nodes in a cursor plan,
such as a scan of an inheritance tree, it's possible to fetch from a
given scan node, then rewind the cursor and fetch some row from an
earlier scan node. In such a case, execCurrent.c mistakenly thought
that the later scan node was still active, because ExecReScan hadn't
done anything to make it look not-active. We'd get some sort of
failure in the case of a SeqScan node, because the node's scan tuple
slot would be pointing at a HeapTuple whose t_self gets reset to
invalid by heapam.c. But it seems possible that for other relation
scan node types we'd actually return a valid tuple TID to the caller,
resulting in updating or deleting a tuple that shouldn't have been
considered current. To fix, forcibly clear the ScanTupleSlot in
ExecScanReScan.
Another issue here, which seems only latent at the moment but could
easily become a live bug in future, is that rewinding a cursor does
not necessarily lead to *immediately* applying ExecReScan to every
scan-level node in the plan tree. Upper-level nodes will think that
they can postpone that call if their child node is already marked
with chgParam flags. I don't see a way for that to happen today in
a plan tree that's simple enough for execCurrent.c's search_plan_tree
to understand, but that's one heck of a fragile assumption. So, add
some logic in search_plan_tree to detect chgParam flags being set on
nodes that it descended to/through, and assume that that means we
should consider lower scan nodes to be logically reset even if their
ReScan call hasn't actually happened yet.
Per bug #15395 from Matvey Arye. This has been broken for a long time,
so back-patch to all supported branches.
Discussion: https://postgr.es/m/153764171023.14986.280404050547008575@wrigleys.postgresql.org
2018-09-23 22:05:45 +02:00
|
|
|
search_plan_tree(PlanState *node, Oid table_oid,
|
|
|
|
bool *pending_rescan)
|
2007-06-11 03:16:30 +02:00
|
|
|
{
|
Fix failure in WHERE CURRENT OF after rewinding the referenced cursor.
In a case where we have multiple relation-scan nodes in a cursor plan,
such as a scan of an inheritance tree, it's possible to fetch from a
given scan node, then rewind the cursor and fetch some row from an
earlier scan node. In such a case, execCurrent.c mistakenly thought
that the later scan node was still active, because ExecReScan hadn't
done anything to make it look not-active. We'd get some sort of
failure in the case of a SeqScan node, because the node's scan tuple
slot would be pointing at a HeapTuple whose t_self gets reset to
invalid by heapam.c. But it seems possible that for other relation
scan node types we'd actually return a valid tuple TID to the caller,
resulting in updating or deleting a tuple that shouldn't have been
considered current. To fix, forcibly clear the ScanTupleSlot in
ExecScanReScan.
Another issue here, which seems only latent at the moment but could
easily become a live bug in future, is that rewinding a cursor does
not necessarily lead to *immediately* applying ExecReScan to every
scan-level node in the plan tree. Upper-level nodes will think that
they can postpone that call if their child node is already marked
with chgParam flags. I don't see a way for that to happen today in
a plan tree that's simple enough for execCurrent.c's search_plan_tree
to understand, but that's one heck of a fragile assumption. So, add
some logic in search_plan_tree to detect chgParam flags being set on
nodes that it descended to/through, and assume that that means we
should consider lower scan nodes to be logically reset even if their
ReScan call hasn't actually happened yet.
Per bug #15395 from Matvey Arye. This has been broken for a long time,
so back-patch to all supported branches.
Discussion: https://postgr.es/m/153764171023.14986.280404050547008575@wrigleys.postgresql.org
2018-09-23 22:05:45 +02:00
|
|
|
ScanState *result = NULL;
|
|
|
|
|
2007-06-11 03:16:30 +02:00
|
|
|
if (node == NULL)
|
|
|
|
return NULL;
|
|
|
|
switch (nodeTag(node))
|
|
|
|
{
|
|
|
|
/*
|
2014-11-20 21:56:39 +01:00
|
|
|
* Relation scan nodes can all be treated alike
|
2007-06-11 03:16:30 +02:00
|
|
|
*/
|
|
|
|
case T_SeqScanState:
|
2015-05-15 20:37:10 +02:00
|
|
|
case T_SampleScanState:
|
2007-06-11 03:16:30 +02:00
|
|
|
case T_IndexScanState:
|
2011-10-11 20:20:06 +02:00
|
|
|
case T_IndexOnlyScanState:
|
2007-06-11 03:16:30 +02:00
|
|
|
case T_BitmapHeapScanState:
|
|
|
|
case T_TidScanState:
|
2014-11-20 21:56:39 +01:00
|
|
|
case T_ForeignScanState:
|
|
|
|
case T_CustomScanState:
|
2007-11-15 22:14:46 +01:00
|
|
|
{
|
|
|
|
ScanState *sstate = (ScanState *) node;
|
2007-06-11 03:16:30 +02:00
|
|
|
|
2007-11-15 22:14:46 +01:00
|
|
|
if (RelationGetRelid(sstate->ss_currentRelation) == table_oid)
|
Fix failure in WHERE CURRENT OF after rewinding the referenced cursor.
In a case where we have multiple relation-scan nodes in a cursor plan,
such as a scan of an inheritance tree, it's possible to fetch from a
given scan node, then rewind the cursor and fetch some row from an
earlier scan node. In such a case, execCurrent.c mistakenly thought
that the later scan node was still active, because ExecReScan hadn't
done anything to make it look not-active. We'd get some sort of
failure in the case of a SeqScan node, because the node's scan tuple
slot would be pointing at a HeapTuple whose t_self gets reset to
invalid by heapam.c. But it seems possible that for other relation
scan node types we'd actually return a valid tuple TID to the caller,
resulting in updating or deleting a tuple that shouldn't have been
considered current. To fix, forcibly clear the ScanTupleSlot in
ExecScanReScan.
Another issue here, which seems only latent at the moment but could
easily become a live bug in future, is that rewinding a cursor does
not necessarily lead to *immediately* applying ExecReScan to every
scan-level node in the plan tree. Upper-level nodes will think that
they can postpone that call if their child node is already marked
with chgParam flags. I don't see a way for that to happen today in
a plan tree that's simple enough for execCurrent.c's search_plan_tree
to understand, but that's one heck of a fragile assumption. So, add
some logic in search_plan_tree to detect chgParam flags being set on
nodes that it descended to/through, and assume that that means we
should consider lower scan nodes to be logically reset even if their
ReScan call hasn't actually happened yet.
Per bug #15395 from Matvey Arye. This has been broken for a long time,
so back-patch to all supported branches.
Discussion: https://postgr.es/m/153764171023.14986.280404050547008575@wrigleys.postgresql.org
2018-09-23 22:05:45 +02:00
|
|
|
result = sstate;
|
2007-11-15 22:14:46 +01:00
|
|
|
break;
|
|
|
|
}
|
2007-06-11 03:16:30 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* For Append, we must look through the members; watch out for
|
|
|
|
* multiple matches (possible if it was from UNION ALL)
|
|
|
|
*/
|
|
|
|
case T_AppendState:
|
|
|
|
{
|
2007-11-15 22:14:46 +01:00
|
|
|
AppendState *astate = (AppendState *) node;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < astate->as_nplans; i++)
|
|
|
|
{
|
|
|
|
ScanState *elem = search_plan_tree(astate->appendplans[i],
|
Fix failure in WHERE CURRENT OF after rewinding the referenced cursor.
In a case where we have multiple relation-scan nodes in a cursor plan,
such as a scan of an inheritance tree, it's possible to fetch from a
given scan node, then rewind the cursor and fetch some row from an
earlier scan node. In such a case, execCurrent.c mistakenly thought
that the later scan node was still active, because ExecReScan hadn't
done anything to make it look not-active. We'd get some sort of
failure in the case of a SeqScan node, because the node's scan tuple
slot would be pointing at a HeapTuple whose t_self gets reset to
invalid by heapam.c. But it seems possible that for other relation
scan node types we'd actually return a valid tuple TID to the caller,
resulting in updating or deleting a tuple that shouldn't have been
considered current. To fix, forcibly clear the ScanTupleSlot in
ExecScanReScan.
Another issue here, which seems only latent at the moment but could
easily become a live bug in future, is that rewinding a cursor does
not necessarily lead to *immediately* applying ExecReScan to every
scan-level node in the plan tree. Upper-level nodes will think that
they can postpone that call if their child node is already marked
with chgParam flags. I don't see a way for that to happen today in
a plan tree that's simple enough for execCurrent.c's search_plan_tree
to understand, but that's one heck of a fragile assumption. So, add
some logic in search_plan_tree to detect chgParam flags being set on
nodes that it descended to/through, and assume that that means we
should consider lower scan nodes to be logically reset even if their
ReScan call hasn't actually happened yet.
Per bug #15395 from Matvey Arye. This has been broken for a long time,
so back-patch to all supported branches.
Discussion: https://postgr.es/m/153764171023.14986.280404050547008575@wrigleys.postgresql.org
2018-09-23 22:05:45 +02:00
|
|
|
table_oid,
|
|
|
|
pending_rescan);
|
2007-11-15 22:14:46 +01:00
|
|
|
|
|
|
|
if (!elem)
|
|
|
|
continue;
|
|
|
|
if (result)
|
|
|
|
return NULL; /* multiple matches */
|
|
|
|
result = elem;
|
|
|
|
}
|
Fix failure in WHERE CURRENT OF after rewinding the referenced cursor.
In a case where we have multiple relation-scan nodes in a cursor plan,
such as a scan of an inheritance tree, it's possible to fetch from a
given scan node, then rewind the cursor and fetch some row from an
earlier scan node. In such a case, execCurrent.c mistakenly thought
that the later scan node was still active, because ExecReScan hadn't
done anything to make it look not-active. We'd get some sort of
failure in the case of a SeqScan node, because the node's scan tuple
slot would be pointing at a HeapTuple whose t_self gets reset to
invalid by heapam.c. But it seems possible that for other relation
scan node types we'd actually return a valid tuple TID to the caller,
resulting in updating or deleting a tuple that shouldn't have been
considered current. To fix, forcibly clear the ScanTupleSlot in
ExecScanReScan.
Another issue here, which seems only latent at the moment but could
easily become a live bug in future, is that rewinding a cursor does
not necessarily lead to *immediately* applying ExecReScan to every
scan-level node in the plan tree. Upper-level nodes will think that
they can postpone that call if their child node is already marked
with chgParam flags. I don't see a way for that to happen today in
a plan tree that's simple enough for execCurrent.c's search_plan_tree
to understand, but that's one heck of a fragile assumption. So, add
some logic in search_plan_tree to detect chgParam flags being set on
nodes that it descended to/through, and assume that that means we
should consider lower scan nodes to be logically reset even if their
ReScan call hasn't actually happened yet.
Per bug #15395 from Matvey Arye. This has been broken for a long time,
so back-patch to all supported branches.
Discussion: https://postgr.es/m/153764171023.14986.280404050547008575@wrigleys.postgresql.org
2018-09-23 22:05:45 +02:00
|
|
|
break;
|
2007-06-11 03:16:30 +02:00
|
|
|
}
|
|
|
|
|
2010-10-14 22:56:39 +02:00
|
|
|
/*
|
|
|
|
* Similarly for MergeAppend
|
|
|
|
*/
|
|
|
|
case T_MergeAppendState:
|
|
|
|
{
|
|
|
|
MergeAppendState *mstate = (MergeAppendState *) node;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < mstate->ms_nplans; i++)
|
|
|
|
{
|
|
|
|
ScanState *elem = search_plan_tree(mstate->mergeplans[i],
|
Fix failure in WHERE CURRENT OF after rewinding the referenced cursor.
In a case where we have multiple relation-scan nodes in a cursor plan,
such as a scan of an inheritance tree, it's possible to fetch from a
given scan node, then rewind the cursor and fetch some row from an
earlier scan node. In such a case, execCurrent.c mistakenly thought
that the later scan node was still active, because ExecReScan hadn't
done anything to make it look not-active. We'd get some sort of
failure in the case of a SeqScan node, because the node's scan tuple
slot would be pointing at a HeapTuple whose t_self gets reset to
invalid by heapam.c. But it seems possible that for other relation
scan node types we'd actually return a valid tuple TID to the caller,
resulting in updating or deleting a tuple that shouldn't have been
considered current. To fix, forcibly clear the ScanTupleSlot in
ExecScanReScan.
Another issue here, which seems only latent at the moment but could
easily become a live bug in future, is that rewinding a cursor does
not necessarily lead to *immediately* applying ExecReScan to every
scan-level node in the plan tree. Upper-level nodes will think that
they can postpone that call if their child node is already marked
with chgParam flags. I don't see a way for that to happen today in
a plan tree that's simple enough for execCurrent.c's search_plan_tree
to understand, but that's one heck of a fragile assumption. So, add
some logic in search_plan_tree to detect chgParam flags being set on
nodes that it descended to/through, and assume that that means we
should consider lower scan nodes to be logically reset even if their
ReScan call hasn't actually happened yet.
Per bug #15395 from Matvey Arye. This has been broken for a long time,
so back-patch to all supported branches.
Discussion: https://postgr.es/m/153764171023.14986.280404050547008575@wrigleys.postgresql.org
2018-09-23 22:05:45 +02:00
|
|
|
table_oid,
|
|
|
|
pending_rescan);
|
2010-10-14 22:56:39 +02:00
|
|
|
|
|
|
|
if (!elem)
|
|
|
|
continue;
|
|
|
|
if (result)
|
|
|
|
return NULL; /* multiple matches */
|
|
|
|
result = elem;
|
|
|
|
}
|
Fix failure in WHERE CURRENT OF after rewinding the referenced cursor.
In a case where we have multiple relation-scan nodes in a cursor plan,
such as a scan of an inheritance tree, it's possible to fetch from a
given scan node, then rewind the cursor and fetch some row from an
earlier scan node. In such a case, execCurrent.c mistakenly thought
that the later scan node was still active, because ExecReScan hadn't
done anything to make it look not-active. We'd get some sort of
failure in the case of a SeqScan node, because the node's scan tuple
slot would be pointing at a HeapTuple whose t_self gets reset to
invalid by heapam.c. But it seems possible that for other relation
scan node types we'd actually return a valid tuple TID to the caller,
resulting in updating or deleting a tuple that shouldn't have been
considered current. To fix, forcibly clear the ScanTupleSlot in
ExecScanReScan.
Another issue here, which seems only latent at the moment but could
easily become a live bug in future, is that rewinding a cursor does
not necessarily lead to *immediately* applying ExecReScan to every
scan-level node in the plan tree. Upper-level nodes will think that
they can postpone that call if their child node is already marked
with chgParam flags. I don't see a way for that to happen today in
a plan tree that's simple enough for execCurrent.c's search_plan_tree
to understand, but that's one heck of a fragile assumption. So, add
some logic in search_plan_tree to detect chgParam flags being set on
nodes that it descended to/through, and assume that that means we
should consider lower scan nodes to be logically reset even if their
ReScan call hasn't actually happened yet.
Per bug #15395 from Matvey Arye. This has been broken for a long time,
so back-patch to all supported branches.
Discussion: https://postgr.es/m/153764171023.14986.280404050547008575@wrigleys.postgresql.org
2018-09-23 22:05:45 +02:00
|
|
|
break;
|
2010-10-14 22:56:39 +02:00
|
|
|
}
|
|
|
|
|
2007-06-11 03:16:30 +02:00
|
|
|
/*
|
|
|
|
* Result and Limit can be descended through (these are safe
|
|
|
|
* because they always return their input's current row)
|
|
|
|
*/
|
|
|
|
case T_ResultState:
|
|
|
|
case T_LimitState:
|
Fix failure in WHERE CURRENT OF after rewinding the referenced cursor.
In a case where we have multiple relation-scan nodes in a cursor plan,
such as a scan of an inheritance tree, it's possible to fetch from a
given scan node, then rewind the cursor and fetch some row from an
earlier scan node. In such a case, execCurrent.c mistakenly thought
that the later scan node was still active, because ExecReScan hadn't
done anything to make it look not-active. We'd get some sort of
failure in the case of a SeqScan node, because the node's scan tuple
slot would be pointing at a HeapTuple whose t_self gets reset to
invalid by heapam.c. But it seems possible that for other relation
scan node types we'd actually return a valid tuple TID to the caller,
resulting in updating or deleting a tuple that shouldn't have been
considered current. To fix, forcibly clear the ScanTupleSlot in
ExecScanReScan.
Another issue here, which seems only latent at the moment but could
easily become a live bug in future, is that rewinding a cursor does
not necessarily lead to *immediately* applying ExecReScan to every
scan-level node in the plan tree. Upper-level nodes will think that
they can postpone that call if their child node is already marked
with chgParam flags. I don't see a way for that to happen today in
a plan tree that's simple enough for execCurrent.c's search_plan_tree
to understand, but that's one heck of a fragile assumption. So, add
some logic in search_plan_tree to detect chgParam flags being set on
nodes that it descended to/through, and assume that that means we
should consider lower scan nodes to be logically reset even if their
ReScan call hasn't actually happened yet.
Per bug #15395 from Matvey Arye. This has been broken for a long time,
so back-patch to all supported branches.
Discussion: https://postgr.es/m/153764171023.14986.280404050547008575@wrigleys.postgresql.org
2018-09-23 22:05:45 +02:00
|
|
|
result = search_plan_tree(node->lefttree,
|
|
|
|
table_oid,
|
|
|
|
pending_rescan);
|
|
|
|
break;
|
2007-06-11 03:16:30 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* SubqueryScan too, but it keeps the child in a different place
|
|
|
|
*/
|
|
|
|
case T_SubqueryScanState:
|
Fix failure in WHERE CURRENT OF after rewinding the referenced cursor.
In a case where we have multiple relation-scan nodes in a cursor plan,
such as a scan of an inheritance tree, it's possible to fetch from a
given scan node, then rewind the cursor and fetch some row from an
earlier scan node. In such a case, execCurrent.c mistakenly thought
that the later scan node was still active, because ExecReScan hadn't
done anything to make it look not-active. We'd get some sort of
failure in the case of a SeqScan node, because the node's scan tuple
slot would be pointing at a HeapTuple whose t_self gets reset to
invalid by heapam.c. But it seems possible that for other relation
scan node types we'd actually return a valid tuple TID to the caller,
resulting in updating or deleting a tuple that shouldn't have been
considered current. To fix, forcibly clear the ScanTupleSlot in
ExecScanReScan.
Another issue here, which seems only latent at the moment but could
easily become a live bug in future, is that rewinding a cursor does
not necessarily lead to *immediately* applying ExecReScan to every
scan-level node in the plan tree. Upper-level nodes will think that
they can postpone that call if their child node is already marked
with chgParam flags. I don't see a way for that to happen today in
a plan tree that's simple enough for execCurrent.c's search_plan_tree
to understand, but that's one heck of a fragile assumption. So, add
some logic in search_plan_tree to detect chgParam flags being set on
nodes that it descended to/through, and assume that that means we
should consider lower scan nodes to be logically reset even if their
ReScan call hasn't actually happened yet.
Per bug #15395 from Matvey Arye. This has been broken for a long time,
so back-patch to all supported branches.
Discussion: https://postgr.es/m/153764171023.14986.280404050547008575@wrigleys.postgresql.org
2018-09-23 22:05:45 +02:00
|
|
|
result = search_plan_tree(((SubqueryScanState *) node)->subplan,
|
|
|
|
table_oid,
|
|
|
|
pending_rescan);
|
|
|
|
break;
|
2007-06-11 03:16:30 +02:00
|
|
|
|
|
|
|
default:
|
|
|
|
/* Otherwise, assume we can't descend through it */
|
|
|
|
break;
|
|
|
|
}
|
Fix failure in WHERE CURRENT OF after rewinding the referenced cursor.
In a case where we have multiple relation-scan nodes in a cursor plan,
such as a scan of an inheritance tree, it's possible to fetch from a
given scan node, then rewind the cursor and fetch some row from an
earlier scan node. In such a case, execCurrent.c mistakenly thought
that the later scan node was still active, because ExecReScan hadn't
done anything to make it look not-active. We'd get some sort of
failure in the case of a SeqScan node, because the node's scan tuple
slot would be pointing at a HeapTuple whose t_self gets reset to
invalid by heapam.c. But it seems possible that for other relation
scan node types we'd actually return a valid tuple TID to the caller,
resulting in updating or deleting a tuple that shouldn't have been
considered current. To fix, forcibly clear the ScanTupleSlot in
ExecScanReScan.
Another issue here, which seems only latent at the moment but could
easily become a live bug in future, is that rewinding a cursor does
not necessarily lead to *immediately* applying ExecReScan to every
scan-level node in the plan tree. Upper-level nodes will think that
they can postpone that call if their child node is already marked
with chgParam flags. I don't see a way for that to happen today in
a plan tree that's simple enough for execCurrent.c's search_plan_tree
to understand, but that's one heck of a fragile assumption. So, add
some logic in search_plan_tree to detect chgParam flags being set on
nodes that it descended to/through, and assume that that means we
should consider lower scan nodes to be logically reset even if their
ReScan call hasn't actually happened yet.
Per bug #15395 from Matvey Arye. This has been broken for a long time,
so back-patch to all supported branches.
Discussion: https://postgr.es/m/153764171023.14986.280404050547008575@wrigleys.postgresql.org
2018-09-23 22:05:45 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If we found a candidate at or below this node, then this node's
|
|
|
|
* chgParam indicates a pending rescan that will affect the candidate.
|
|
|
|
*/
|
|
|
|
if (result && node->chgParam != NULL)
|
|
|
|
*pending_rescan = true;
|
|
|
|
|
|
|
|
return result;
|
2007-06-11 03:16:30 +02:00
|
|
|
}
|