From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | kwan(dot)lim(at)gmail(dot)com |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #14659: "ERROR: could not open relation with OID" when creating table from SELECT with large row |
Date: | 2017-05-18 15:11:49 |
Message-ID: | 21218.1495120309@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
kwan(dot)lim(at)gmail(dot)com writes:
> We have a UDF that creates a temporary table from a SELECT statement then
> returns the result and drops the table.
> For certain cases where it appears that there are large strings in some
> columns the UDF fails with: "ERROR: could not open relation with OID"
What seems to be happening is that if the strings are large enough to be
toasted, then the data returned out of the function with RETURN QUERY
contains toast pointers referencing the temp table's toast table.
If you drop the temp table then those pointers will fail upon use.
In this particular example there's an obvious workaround: lose the final
DROP TABLE. The function's initial "DROP IF EXISTS" will serve just fine.
It seems like what we'd have to do to fix this is to detoast datums
that are going into the returned tuplestore. That's pretty annoying
from a performance standpoint, but I don't see any good alternative.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | tbrandys | 2017-05-18 16:09:16 | BUG #14660: Conversion to UTC not properly computed |
Previous Message | kwan.lim | 2017-05-18 14:24:43 | BUG #14659: "ERROR: could not open relation with OID" when creating table from SELECT with large row |