Skip site navigation (1) Skip section navigation (2)

Re: Could not open relation with OID (table partitioning issue?)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "mark" <dvlhntr(at)gmail(dot)com>
Cc: "'bakkiya'" <bakkiya(at)gmail(dot)com>, pgsql-novice(at)postgresql(dot)org
Subject: Re: Could not open relation with OID (table partitioning issue?)
Date: 2010-11-22 15:09:46
Message-ID: 26145.1290438586@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-novice
"mark" <dvlhntr(at)gmail(dot)com> writes:
> I don't know if this is a bug and if so, if it fixed in the most current
> patch. (I don't see anything in the release notes that make think so though
> however).

At least one reason for this type of problem was fixed in 8.4.

commit d4a363cdf2b426bbf6c401543b8286ad86ca9bd5
Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Date:   Tue May 12 03:11:02 2009 +0000

    Modify find_inheritance_children() and find_all_inheritors() to add the
    ability to lock relations as they scan pg_inherits, and to ignore any
    relations that have disappeared by the time we get lock on them.  This
    makes uses of these functions safe against concurrent DROP operations
    on child tables: we will effectively ignore any just-dropped child,
    rather than possibly throwing an error as in recent bug report from
    Thomas Johansson (and similar past complaints).  The behavior should
    not change otherwise, since the code was acquiring those same locks
    anyway, just a little bit later.
    
    An exception is LockTableCommand(), which is still behaving unsafely;
    but that seems to require some more discussion before we change it.

			regards, tom lane

In response to

Responses

pgsql-novice by date

Next:From: Richard BroersmaDate: 2010-11-22 17:20:00
Subject: Re: Change Data Capture
Previous:From: Tom LaneDate: 2010-11-22 14:43:07
Subject: Re: Null values detected as 0 value

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group