| 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 |
| Subject: | Re: Possible bug: could not open relation with OID [numbers] SQL State: XX000 |
| Date: | 2017-11-02 03:12:33 |
| Message-ID: | 21716.1509592353@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:
> Huh, so in the other cases where the function works fine, it's likely that
> the data all just fits within the regular table and doesn't have to be
> TOAST'ed?
If that's the correct theory, yes. Did you match up the OID yet?
> So this is something that isn't changed in PG10, and I could have
> encountered in 9.6, and just by chance didn't?
You could have encountered it anytime since TOAST was invented, or at
least since RETURN QUERY was invented (the latter is newer IIRC).
The fact that the bug has been there so long and has only been reported
a couple of times is the main reason why I'm loath to take a brute
force duplicate-the-data approach to fixing it. Such a fix would
penalize many more people than it would help.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Adam Brusselback | 2017-11-02 03:35:20 | Re: Possible bug: could not open relation with OID [numbers] SQL State: XX000 |
| Previous Message | Adam Brusselback | 2017-11-02 02:36:29 | Re: Possible bug: could not open relation with OID [numbers] SQL State: XX000 |