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

-----Original Message-----
From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Monday, November 22, 2010 8:10 AM
To: mark
Cc: 'bakkiya'; pgsql-novice(at)postgresql(dot)org
Subject: Re: [NOVICE] Could not open relation with OID (table partitioning
issue?)

>"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

So is my adding a access exclusive lock to the parent table when dropping
children a bad thing (tm), in terms of introducing an error, since it uses
the locktablecommand()?

Still riding 8.3.7 here but wanted to keep this in mind for 9.0.1 and higher
when I migrate.

Thanks

-Mark