Doing the upgrade with an installation built from REL9_3_STABLE at
commit 52eed3d4267faf671dae0450d99982cb9ba1ac52 was successful.

The view that I saw get re-created as a table doesn't have any circular
references, or indeed any references to other views, nor do any other views
reference it.  But since it does seem that there are valid cases where a
view gets temporarily re-created as a table during an upgrade, I'm going to
assume it's not a bug per se.  My upgraded cluster using built-from-source
binaries has these views as views, so when the process is complete they end
up in the correct state.

Is there an expected release date for 9.3.6?

On Thu, Sep 4, 2014 at 2:01 PM, Bruce Momjian <> wrote:

> On Thu, Sep  4, 2014 at 03:48:17PM -0400, Robert Haas wrote:
> > On Thu, Sep 4, 2014 at 3:35 PM, Bruce Momjian <> wrote:
> > >> At any rate, I've additionally observed that the relation which is
> blowing up
> > >> pg_upgrade is a VIEW in the source cluster but gets created as a
> TABLE in the
> > >> upgraded cluster, which may better explain why it had no toast table
> before and
> > >> now it does.  Is this some kind of expected behavior for views?
> > >
> > > Uh, it certainly should not be creating a table instead of a view,
> > > though it will get a pg_class entry.
> >
> > Actually, there's a way this can happen.  If you create two (or more)
> > views with circular dependencies between them, then pg_dump will emit
> > commands to create one of them as a table first, then create the
> > others as views, then convert the first table to a view by adding a
> > _SELECT rule to it.
> Wow, that's super-interesting.
> > If pg_upgrade's logic can't cope with that, that's a bug in
> > pg_upgrade, because there's no other way to restore views with
> > circular dependency chains.
> I don't see why pg_upgrade would have any problem with it as it just
> looks at the old schema and post-restore schema.
> --
>   Bruce Momjian  <>
>   EnterpriseDB                   
>   + Everyone has their own god. +

Reply via email to