From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Noah Misch <noah(at)leadboat(dot)com>, Philippe BEAUDOIN <phb(dot)emaj(at)free(dot)fr>, PostgreSQL mailing lists <pgsql-general(at)postgresql(dot)org>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] pg_dumping extensions having sequences with 9.6beta3 |
Date: | 2016-07-29 16:10:24 |
Message-ID: | CA+TgmoYNiVHHydOs9iVpa1YOSyH=AYHrDdbVUmOCrid5cTQEkw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On Wed, Jul 27, 2016 at 2:24 AM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Wed, Jul 27, 2016 at 8:07 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>> That'd be great. It's definitely on my list of things to look into, but
>> I'm extremely busy this week. I hope to look into it on Friday, would
>> be great to see what you find.
>
> Sequences that are directly defined in extensions do not get dumped,
> and sequences that are part of a serial column in an extension are
> getting dumped. Looking into this problem, getOwnedSeqs() is visibly
> doing an incorrect assumption: sequences owned by table columns are
> dumped unconditionally, but this is not true for sequences that are
> part of extensions. More precisely, dobj->dump is being enforced to
> DUMP_COMPONENT_ALL, which makes the sequence definition to be dumped.
> Oops.
>
> The patch attached fixes the problem for me. I have added as well
> tests in test_pg_dump in the shape of sequences defined in an
> extension, and sequences that are part of a serial column. This patch
> is also able to work in the case where a sequence is created as part
> of a serial column, and gets removed after, say with ALTER EXTENSION
> DROP SEQUENCE. The behavior for sequences and serial columns that are
> not part of extensions is unchanged.
>
> Stephen, it would be good if you could check the correctness of this
> patch as you did all this refactoring of pg_dump to support catalog
> ACLs. I am sure by the way that checking for (owning_tab->dobj.dump &&
> DUMP_COMPONENT_DEFINITION) != 0 is not good because of for example the
> case of a serial column created in an extension where the sequence is
> dropped from the extension afterwards.
Stephen, is this still on your list of things for today? Please
provide a status update.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-07-29 16:15:29 | Re: 9.6beta3 |
Previous Message | Joshua D. Drake | 2016-07-29 16:10:19 | Re: 9.6beta3 |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-07-29 16:17:43 | Re: [sqlsmith] Failed assertion in joinrels.c |
Previous Message | Robert Haas | 2016-07-29 16:08:41 | Re: [sqlsmith] Failed assertion in joinrels.c |