From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Adam Brusselback <adambrusselback(at)gmail(dot)com> |
Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Possible bug: could not open relation with OID [numbers] SQL State: XX000 |
Date: | 2017-11-02 01:36:35 |
Message-ID: | 13901.1509586595@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Adam Brusselback <adambrusselback(at)gmail(dot)com> writes:
> The OID does not match any of the temp tables, so not sure what's up there.
> I have the function RETURN QUERY,
> and then I drop all my temp tables.
I'll bet the OID corresponds to the toast table for one of those temp
tables. RETURN QUERY will stash away all the values read by the query,
but it doesn't make an attempt to inline out-of-line values; so you get
a failure when the out-of-line column value is eventually demanded.
I think we've seen one previous complaint of the same ilk. Probably
somebody will get annoyed enough to fix it at some point, but the
sticking point is how to cover this corner case without causing a
performance drop for normal cases. In the meantime, maybe you could
make the temp tables be ON COMMIT DROP instead of dropping them
explicitly mid-transaction.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Adam Brusselback | 2017-11-02 02:36:29 | Re: Possible bug: could not open relation with OID [numbers] SQL State: XX000 |
Previous Message | Adam Brusselback | 2017-11-01 23:30:04 | Re: Possible bug: could not open relation with OID [numbers] SQL State: XX000 |