From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | "PostgreSQL-development Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCHES] Eliminate more detoast copies for packed varlenas |
Date: | 2007-10-11 20:03:36 |
Message-ID: | 5324.1192133016@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Gregory Stark <stark(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2007-10-11 20:04:40 | Release notes introductory text |
Previous Message | Michael Paesold | 2007-10-11 19:59:08 | Re: First steps with 8.3 and autovacuum launcher |
From | Date | Subject | |
---|---|---|---|
Next Message | Marko Kreen | 2007-10-11 20:48:19 | Re: txid cleanup |
Previous Message | Tom Lane | 2007-10-11 19:55:04 | Re: txid cleanup |