Re: Error with temporary tables - Mailing list pgsql-general

From Claire McLister
Subject Re: Error with temporary tables
Date
Msg-id D2D36981-3956-4011-B258-58302E1CFEE0@zeesource.net
Whole thread Raw
In response to Re: Error with temporary tables  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Error with temporary tables  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Thanks. So, the hack we  did is okay then? Does using the substring
function de-TOAST it?

On Feb 4, 2006, at 11:24 AM, Tom Lane wrote:

> Claire McLister <mclister@zeesource.net> writes:
>> This was all working fine until E.Value became some large strings
>> with some occasional funny characters.
>
>> The hack that solved the problem was:
>
>>   R.Field := substring(E.Value from 1);
>
>>   This is a complete hack, so I'd like to find out what is going
>> wrong and why this worked. For now, it keeps the system functional.
>
> Oooh.  You were probably dealing with values that had gotten large
> enough to be "toasted", ie, stored out-of-line in a TOAST table.
> So the datum being passed around in memory was just a pointer to the
> row in the TOAST table.  Dropping the temp table made its TOAST table
> go away, resulting in a dangling pointer stored in the plpgsql
> variable.
>
> The easy fix would be to forcibly detoast any value stored into a
> plpgsql variable, but the performance implications of that seem a
> bit nasty.  Not sure I want to do it for such a weird corner case...
>
>             regards, tom lane
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings


pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Error with temporary tables
Next
From: "George Pavlov"
Date:
Subject: information_schema.columns.column_default filtered based on user