diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2015-03-12 13:38:49 -0400 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2015-03-12 13:38:49 -0400 |
commit | 5bdf3cf5ad3048e8376fff6ccf5dafd0e9d2e603 (patch) | |
tree | c8c11ebb5b5486778d65a708b4d108322ef77a21 /src/backend/executor/execMain.c | |
parent | d16d821faa5a2c97e2fb532daa9a032b48129c91 (diff) | |
download | postgresql-5bdf3cf5ad3048e8376fff6ccf5dafd0e9d2e603.tar.gz postgresql-5bdf3cf5ad3048e8376fff6ccf5dafd0e9d2e603.zip |
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.
Diffstat (limited to 'src/backend/executor/execMain.c')
-rw-r--r-- | src/backend/executor/execMain.c | 4 |
1 files changed, 3 insertions, 1 deletions
diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c index 333c70bca48..99f7a049930 100644 --- a/src/backend/executor/execMain.c +++ b/src/backend/executor/execMain.c @@ -2335,7 +2335,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 */ |