From: | Martín Marqués <martin(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] PgQ and pg_dump |
Date: | 2016-06-21 16:45:19 |
Message-ID: | CAPdiE1z_0dQUO7Ookf2yinB4bUk8pg3DuDRV4qTt4XFRi7C1xw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
2016-06-21 13:08 GMT-03:00 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Thu, Jun 16, 2016 at 1:46 PM, Martín Marqués <martin(at)2ndquadrant(dot)com> wrote:
>> The comment is accurate on what is going to be dumpable and what's not
>> from the code. In our case, as the pgq schema is not dumpable becaause
>> it comes from an extension, other objects it contain will not be
>> dumpable as well.
>>
>> That's the reason why the PgQ event tables created by
>> pgq.create_queue() are not dumped.
>
> That sucks.
Yes, and I'm surprised we haven't had any bug report yet on
inconsistent dumps. The patch that changed pg_dump's behavior on
extension objects is more then a year old.
I'll find some time today to add tests and check for other objects
that are not dumped for the same reason.
Cheers,
--
Martín Marqués http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Ramalingam, Sankarakumar | 2016-06-21 19:34:18 | Help on recovering my standby |
Previous Message | Robert Haas | 2016-06-21 16:08:28 | Re: [HACKERS] PgQ and pg_dump |
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2016-06-21 16:54:15 | Re: Reviewing freeze map code |
Previous Message | Bruce Momjian | 2016-06-21 16:20:46 | Re: Choosing the cheapest optimizer cost |