From: Tom Lane Date: Thu, 12 Mar 2015 17:38:49 +0000 (-0400) Subject: Ensure tableoid reads correctly in EvalPlanQual-manufactured tuples. X-Git-Tag: REL9_2_11~53 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=590fc5d96f8b880fd41c4992dab73ec47f90eca4;p=postgresql 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. --- diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c index ea81c361ed..df6af1b898 100644 --- a/src/backend/executor/execMain.c +++ b/src/backend/executor/execMain.c @@ -2238,7 +2238,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 */