Skip site navigation (1) Skip section navigation (2)

pgsql: Fix an oversight in the support for storing/retrieving "minimal

From: tgl(at)postgresql(dot)org (Tom Lane)
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Fix an oversight in the support for storing/retrieving "minimal
Date: 2009-03-30 04:08:43
Message-ID: 20090330040843.E8366754ADE@cvs.postgresql.org (view raw or flat)
Thread:
Lists: pgsql-committers
Log Message:
-----------
Fix an oversight in the support for storing/retrieving "minimal tuples" in
TupleTableSlots.  We have functions for retrieving a minimal tuple from a slot
after storing a regular tuple in it, or vice versa; but these were implemented
by converting the internal storage from one format to the other.  The problem
with that is it invalidates any pass-by-reference Datums that were already
fetched from the slot, since they'll be pointing into the just-freed version
of the tuple.  The known problem cases involve fetching both a whole-row
variable and a pass-by-reference value from a slot that is fed from a
tuplestore or tuplesort object.  The added regression tests illustrate some
simple cases, but there may be other failure scenarios traceable to the same
bug.  Note that the added tests probably only fail on unpatched code if it's
built with --enable-cassert; otherwise the bug leads to fetching from freed
memory, which will not have been overwritten without additional conditions.

Fix by allowing a slot to contain both formats simultaneously; which turns out
not to complicate the logic much at all, if anything it seems less contorted
than before.

Back-patch to 8.2, where minimal tuples were introduced.

Modified Files:
--------------
    pgsql/src/backend/access/common:
        heaptuple.c (r1.125 -> r1.126)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/common/heaptuple.c?r1=1.125&r2=1.126)
    pgsql/src/backend/executor:
        execTuples.c (r1.105 -> r1.106)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/execTuples.c?r1=1.105&r2=1.106)
    pgsql/src/include/executor:
        tuptable.h (r1.40 -> r1.41)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/executor/tuptable.h?r1=1.40&r2=1.41)
    pgsql/src/test/regress/expected:
        rangefuncs.out (r1.20 -> r1.21)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/rangefuncs.out?r1=1.20&r2=1.21)
        with.out (r1.9 -> r1.10)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/with.out?r1=1.9&r2=1.10)
    pgsql/src/test/regress/sql:
        rangefuncs.sql (r1.9 -> r1.10)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/rangefuncs.sql?r1=1.9&r2=1.10)
        with.sql (r1.8 -> r1.9)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/with.sql?r1=1.8&r2=1.9)

pgsql-committers by date

Next:From: Tom LaneDate: 2009-03-30 04:09:09
Subject: pgsql: Fix an oversight in the support for storing/retrieving "minimal
Previous:From: Alvaro HerreraDate: 2009-03-30 02:01:03
Subject: Re: Re: [COMMITTERS] pgsql: Temporarily (I hope) disableflattening of IN/EXISTS sublinks

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group