From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Noah Yetter <nyetter(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Pg_upgrade and toast tables bug discovered |
Date: | 2014-09-04 19:48:17 |
Message-ID: | CA+TgmoYGvq2DJCq8EfsF_KkDj3cr=C3zQnFEe=DLuSQ2P_r2mw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Sep 4, 2014 at 3:35 PM, Bruce Momjian <bruce(at)momjian(dot)us> 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.
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Zhaomo Yang | 2014-09-04 19:49:35 | A mechanism securing web applications in DBMS |
Previous Message | Stephen Frost | 2014-09-04 19:42:36 | Re: Commitfest status |