Re: [PATCHES] Eliminate more detoast copies for packed varlenas - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCHES] Eliminate more detoast copies for packed varlenas
Date
Msg-id 5324.1192133016@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCHES] Eliminate more detoast copies for packed varlenas  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: [PATCHES] Eliminate more detoast copies for packed varlenas  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Gregory Stark <stark@enterprisedb.com> writes:
> For the record I've been doing some more testing and found one place that
> could be a problem down the road. I'm not sure why it didn't show up
> previously. In selfuncs.c we use VARDATA/VARSIZE on data that is taken from
> parser Const nodes and from the histogram arrays without detoasting them.

> Currently this is safe as array elements are not packed and parser nodes
> contain values read using textin and never stored in a tuple. But down the
> road I expect we'll want to pack array element so this code would need to
> detoast the elements or prepare to handle packed elements.

Hmmm ... I think this should be fixed now, actually.  I'm far from
convinced that a Const could never contain a toasted datum.  Consider
constant-folding in the planner --- it just stuffs the result of a
function into a Const node.

In fact, it seems there's a different risk here: if such a datum were
toasted out-of-line, the reference in a cached plan might live longer
than the underlying toast-table data.  Maybe we need a forcible detoast
in evaluate_function().
        regards, tom lane


pgsql-hackers by date:

Previous
From: Michael Paesold
Date:
Subject: Re: First steps with 8.3 and autovacuum launcher
Next
From: Bruce Momjian
Date:
Subject: Release notes introductory text