postgres.git / summary / log / commit / refs
commit 4a4fd2b0ceedb339118b0cf10ca78e472ce20a90
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date: Thu Mar 12 17:38:49 2015 +0000
First released in: 9.5.0, 9.1.16, 9.2.11, 9.3.7, 9.4.2
Ensure tableoid reads correctly in EvalPlanQual-manufactured tuples.
The ROW_MARK_COPY path in EvalPlanQualFetchRowMarks() was just setting
tableoid to InvalidOid, I think on the assumption that the referenced
RTE must be a subquery or other case without a meaningful OID. However,
foreign tables also use this code path, and they do have meaningful
table OIDs; so failure to set the tuple field can lead to user-visible
misbehavior. Fix that by fetching the appropriate OID from the range
table.
There's still an issue about whether CTID can ever have a meaningful
value in this case; at least with postgres_fdw foreign tables, it does.
But that is a different problem that seems to require a significantly
different patch --- it's debatable whether postgres_fdw really wants to
use this code path at all.
Simplified version of a patch by Etsuro Fujita, who also noted the
problem to begin with. The issue can be demonstrated in all versions
having FDWs, so back-patch to 9.1.
src/backend/executor/execMain.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c
index cd0def4aab9..d46cdf8c349 100644
--- a/src/backend/executor/execMain.c
+++ b/src/backend/executor/execMain.c
@@ -2105,7 +2105,9 @@ EvalPlanQualFetchRowMarks(EPQState *epqstate)
/* build a temporary HeapTuple control structure */
tuple.t_len = HeapTupleHeaderGetDatumLength(td);
ItemPointerSetInvalid(&(tuple.t_self));
- tuple.t_tableOid = InvalidOid;
+ /* relation might be a foreign table, if so provide tableoid */
+ tuple.t_tableOid = getrelid(erm->rti,
+ epqstate->estate->es_range_table);
tuple.t_data = td;
/* copy and store tuple */
[parent: 92bb008d8b62]