database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-29 10:41:53 +03:00
Code Activity

Ensure tableoid reads correctly in EvalPlanQual-manufactured tuples.

Browse Source 
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.
This commit is contained in:
Tom Lane
2015-03-12 13:38:49 -04:00
parent ae67e81edb
commit 590fc5d96f
1 changed files with 3 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
src/backend/executor/execMain.c
View File

@ -2238,7 +2238,9 @@ EvalPlanQualFetchRowMarks(EPQState *epqstate)
/* build a temporary HeapTuple control structure */ /* build a temporary HeapTuple control structure */
tuple.t_len = HeapTupleHeaderGetDatumLength(td); tuple.t_len = HeapTupleHeaderGetDatumLength(td);
ItemPointerSetInvalid(&(tuple.t_self)); 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; tuple.t_data = td;
/* copy and store tuple */ /* copy and store tuple */