diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2015-02-15 23:26:45 -0500 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2015-02-15 23:26:45 -0500 |
| commit | 1bf32972e6daf91329ceacca80e5ba67068882bb (patch) | |
| tree | d0ae706b525b7f4c551f93f9467fc9d708f0c335 /src/backend/executor | |
| parent | 9a165aa0b40d47e32b69d03ca6980647dfa76b4e (diff) | |
| download | postgresql-1bf32972e6daf91329ceacca80e5ba67068882bb.tar.gz postgresql-1bf32972e6daf91329ceacca80e5ba67068882bb.zip | |
Fix null-pointer-deref crash while doing COPY IN with check constraints.
In commit bf7ca15875988a88e97302e012d7c4808bef3ea9 I introduced an
assumption that an RTE referenced by a whole-row Var must have a valid eref
field. This is false for RTEs constructed by DoCopy, and there are other
places taking similar shortcuts. Perhaps we should make all those places
go through addRangeTableEntryForRelation or its siblings instead of having
ad-hoc logic, but the most reliable fix seems to be to make the new code in
ExecEvalWholeRowVar cope if there's no eref. We can reasonably assume that
there's no need to insert column aliases if no aliases were provided.
Add a regression test case covering this, and also verifying that a sane
column name is in fact available in this situation.
Although the known case only crashes in 9.4 and HEAD, it seems prudent to
back-patch the code change to 9.2, since all the ingredients for a similar
failure exist in the variant patch applied to 9.3 and 9.2.
Per report from Jean-Pierre Pelletier.
Diffstat (limited to 'src/backend/executor')
| -rw-r--r-- | src/backend/executor/execQual.c | 7 |
1 files changed, 5 insertions, 2 deletions
diff --git a/src/backend/executor/execQual.c b/src/backend/executor/execQual.c index 88af73575c0..2585c0deedb 100644 --- a/src/backend/executor/execQual.c +++ b/src/backend/executor/execQual.c @@ -900,7 +900,9 @@ ExecEvalWholeRowVar(WholeRowVarExprState *wrvstate, ExprContext *econtext, * If we can't locate the RTE, assume the column names we've got are OK. * (As of this writing, the only cases where we can't locate the RTE are * in execution of trigger WHEN clauses, and then the Var will have the - * trigger's relation's rowtype, so its names are fine.) + * trigger's relation's rowtype, so its names are fine.) Also, if the + * creator of the RTE didn't bother to fill in an eref field, assume our + * column names are OK. (This happens in COPY, and perhaps other places.) */ if (econtext->ecxt_estate && variable->varno <= list_length(econtext->ecxt_estate->es_range_table)) @@ -908,7 +910,8 @@ ExecEvalWholeRowVar(WholeRowVarExprState *wrvstate, ExprContext *econtext, RangeTblEntry *rte = rt_fetch(variable->varno, econtext->ecxt_estate->es_range_table); - ExecTypeSetColNames(output_tupdesc, rte->eref->colnames); + if (rte->eref) + ExecTypeSetColNames(output_tupdesc, rte->eref->colnames); } /* Bless the tupdesc if needed, and save it in the execution state */ |