Bug fix confirmation: could not open relation with OID nnn

Started by Aryeh Leib Taurogalmost 12 years ago2 messagesbugs
Jump to latest
#1Aryeh Leib Taurog
vim@aryehleib.com

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&gt;

This seems to be the topic of conversation here:
</messages/by-id/12791.1310599941@sss.pgh.pa.us
</messages/by-id/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

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

#2Bruce Momjian
bruce@momjian.us
In reply to: Aryeh Leib Taurog (#1)
Re: Bug fix confirmation: could not open relation with OID nnn

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&gt;

This seems to be the topic of conversation here:
</messages/by-id/12791.1310599941@sss.pgh.pa.us
</messages/by-id/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. +

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs