pgsql: Fix potential failure when hashing the output of a subplan that

From: tgl(at)postgresql(dot)org (Tom Lane)
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Fix potential failure when hashing the output of a subplan that
Date: 2010-07-28 04:51:27
Message-ID: 20100728045127.4E7957541D5@cvs.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Log Message:
-----------
Fix potential failure when hashing the output of a subplan that produces
a pass-by-reference datatype with a nontrivial projection step.
We were using the same memory context for the projection operation as for
the temporary context used by the hashtable routines in execGrouping.c.
However, the hashtable routines feel free to reset their temp context at
any time, which'd lead to destroying input data that was still needed.
Report and diagnosis by Tao Ma.

Back-patch to 8.1, where the problem was introduced by the changes that
allowed us to work with "virtual" tuples instead of materializing intermediate
tuple values everywhere. The earlier code looks quite similar, but it doesn't
suffer the problem because the data gets copied into another context as a
result of having to materialize ExecProject's output tuple.

Tags:
----
REL8_1_STABLE

Modified Files:
--------------
pgsql/src/backend/executor:
nodeSubplan.c (r1.70.2.3 -> r1.70.2.4)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/nodeSubplan.c?r1=1.70.2.3&r2=1.70.2.4)
pgsql/src/include/nodes:
execnodes.h (r1.139.2.4 -> r1.139.2.5)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/nodes/execnodes.h?r1=1.139.2.4&r2=1.139.2.5)
pgsql/src/test/regress/expected:
subselect.out (r1.13.2.4 -> r1.13.2.5)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/subselect.out?r1=1.13.2.4&r2=1.13.2.5)
pgsql/src/test/regress/sql:
subselect.sql (r1.8.2.4 -> r1.8.2.5)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/subselect.sql?r1=1.8.2.4&r2=1.8.2.5)

Browse pgsql-committers by date

  From Date Subject
Next Message Simon Riggs 2010-07-28 05:22:24 pgsql: Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE
Previous Message Tom Lane 2010-07-28 04:51:21 pgsql: Fix potential failure when hashing the output of a subplan that