]> granicus.if.org Git - postgresql/commit
Mark read/write expanded values as read-only in ExecProject().
authorTom Lane <tgl@sss.pgh.pa.us>
Fri, 3 Jun 2016 19:14:35 +0000 (15:14 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Fri, 3 Jun 2016 19:14:50 +0000 (15:14 -0400)
commit69f526aa4947135f2570c4ec545f6387d4b14585
tree2d4ce4144f8d6b801197eb0a45e17da585b4308f
parent04ae11f62e643e07c411c4935ea6af46cb112aa9
Mark read/write expanded values as read-only in ExecProject().

If a plan node output expression returns an "expanded" datum, and that
output column is referenced in more than one place in upper-level plan
nodes, we need to ensure that what is returned is a read-only reference
not a read/write reference.  Otherwise one of the referencing sites could
scribble on or even delete the expanded datum before we have evaluated the
others.  Commit 1dc5ebc9077ab742, which introduced this feature, supposed
that it'd be sufficient to make SubqueryScan nodes force their output
columns to read-only state.  The folly of that was revealed by bug #14174
from Andrew Gierth, and really should have been immediately obvious
considering that the planner will happily optimize SubqueryScan nodes
out of the plan without any regard for this issue.

The safest fix seems to be to make ExecProject() force its results into
read-only state; that will cover every case where a plan node returns
expression results.  Actually we can delegate this to ExecTargetList()
since we can recursively assume that plain Vars will not reference
read-write datums.  That should keep the extra overhead down to something
minimal.  We no longer need ExecMakeSlotContentsReadOnly(), which was
introduced only in support of the idea that just a few plan node types
would need to do this.

In the future it would be nice to have the planner account for this problem
and inject force-to-read-only expression evaluation nodes into only the
places where there's a risk of multiple evaluation.  That's not a suitable
solution for 9.5 or even 9.6 at this point, though.

Report: <20160603124628.9932.41279@wrigleys.postgresql.org>
src/backend/executor/execQual.c
src/backend/executor/execTuples.c
src/backend/executor/nodeSubqueryscan.c
src/include/executor/tuptable.h
src/test/regress/expected/plpgsql.out
src/test/regress/sql/plpgsql.sql