Thread: Bug fix confirmation: could not open relation with OID nnn

Bug fix confirmation: could not open relation with OID nnn

From
Aryeh Leib Taurog
Date:
I'd like to do the following for large frequent updates on central
table with ~1m rows:

1. Create new table like original
2. Populate new table
3. DROP original table
4. RENAME new table to original

Some testing revealed that in pg 8.4 and 9.1, if another session
queries the table between 3 and 4, the query fails with error 'could
not open relation with OID nnn.'  In pg 9.3 there's no error.
<https://gist.github.com/altaurog/ab0019837719d2a93e6b>

This seems to be the topic of conversation here:
<http://www.postgresql.org/message-id/flat/12791.1310599941@sss.pgh.pa.us#12791.1310599941@sss.pgh.pa.us>
<http://www.postgresql.org/message-id/flat/20285.1340769074@sss.pgh.pa.us#20285.1340769074@sss.pgh.pa.us>

Do I correctly infer that the change in behavior was an intentional
fix and that with pg >= 9.3 I can rely on the above method working
without any risk of this error in my queries?

Much appreciated,
Aryeh Leib Taurog

Re: Bug fix confirmation: could not open relation with OID nnn

From
Bruce Momjian
Date:
On Thu, Jul 10, 2014 at 02:21:57PM +0300, Aryeh Leib Taurog wrote:
> I'd like to do the following for large frequent updates on central
> table with ~1m rows:
>
> 1. Create new table like original
> 2. Populate new table
> 3. DROP original table
> 4. RENAME new table to original
>
> Some testing revealed that in pg 8.4 and 9.1, if another session
> queries the table between 3 and 4, the query fails with error 'could
> not open relation with OID nnn.'  In pg 9.3 there's no error.
> <https://gist.github.com/altaurog/ab0019837719d2a93e6b>
>
> This seems to be the topic of conversation here:
> <http://www.postgresql.org/message-id/flat/12791.1310599941@sss.pgh.pa.us#12791.1310599941@sss.pgh.pa.us>
> <http://www.postgresql.org/message-id/flat/20285.1340769074@sss.pgh.pa.us#20285.1340769074@sss.pgh.pa.us>
>
> Do I correctly infer that the change in behavior was an intentional
> fix and that with pg >= 9.3 I can rely on the above method working
> without any risk of this error in my queries?

Yes, I think so.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +