From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Martín Marqués <martin(at)2ndquadrant(dot)com> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [GENERAL] PgQ and pg_dump |
Date: | 2016-06-16 12:48:55 |
Message-ID: | CAB7nPqRMORW4yqRYZzwp-8+FhbNTCcbQH3jJKz+im-MEz+mEDA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On Thu, Jun 16, 2016 at 8:37 PM, Martín Marqués <martin(at)2ndquadrant(dot)com> wrote:
> El 16/06/16 a las 00:08, Michael Paquier escribió:
>> On Wed, Jun 15, 2016 at 7:19 PM, Martín Marqués <martin(at)2ndquadrant(dot)com> wrote:
>>>
>>> How would the recovery process work? We expect the schema to be there
>>> when restoring the tables?
>>
>> pg_dump creates the schema first via the CREATE EXTENSION command,
>> then tables dependent on this schema that are not created by the
>> extension are dumped individually.
>
> That's not the behavior I'm seeing here:
> [long test]
Yes, that's why I completely agree that this is a bug :)
I am seeing the same behavior as you do.
> This problem came up due to a difference between pg_dump on 9.1.12 and
> 9.1.22 (I believe it was due to a patch on pg_dump that excluded the
> dependent objects from being dumped), but here I'm using 9.5.3:
Hm. I don't recall anything in pg_dump lately except ebd092b, but that
fixed another class of problems.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Martín Marqués | 2016-06-16 13:05:34 | Re: [GENERAL] PgQ and pg_dump |
Previous Message | Martín Marqués | 2016-06-16 11:37:45 | Re: [GENERAL] PgQ and pg_dump |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-06-16 13:00:14 | Re: [sqlsmith] Failed assertion in postgres_fdw/deparse.c:1116 |
Previous Message | Magnus Hagander | 2016-06-16 12:05:39 | pg_upgrade vs vacuum_cost_delay |