Re: [GENERAL] PgQ and pg_dump

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

In response to

Responses

Browse pgsql-general by date

  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

Browse pgsql-hackers by date

  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