On Wed, Jan 18, 2017 at 11:45 PM, Stephen Frost <sfrost@snowman.net> wrote:
> * Daniele Varrazzo (daniele.varrazzo@gmail.com) wrote:
>> On Wed, Jan 18, 2017 at 2:24 PM, Stephen Frost <sfrost@snowman.net> wrote:
>> > * Daniele Varrazzo (daniele.varrazzo@gmail.com) wrote:
>> >> pg_extension_config_dump() doesn't appear working on sequences; the
>> >> resulting dump doesn't contain the state of the sequence. Tested on pg
>> >> 9.6.1 on Ubuntu. This seems a regression from pg 9.5.
>> >
>> > Thanks for the detailed bug report, I'll take a look at it.
>>
>> No problem. A detail maybe not clear (it's in the title, not in the
>> email): the error should be in pg_dump, not in the
>> pg_extension_config_dump() function, as I've found it using 9.6
>> pg_dump against a 9.5 database.
>
> Right, it's most likely something to do with the reworking of pg_dump
> that I did for 9.6.
As far as I can see, the code path to dumpSequenceData() is taken
correctly for such a sequence. processExtensionTables() creates a
dataObj using makeTableDataInfo() only for sequences in extensions
that are dumpable. So I have been wondering what's happening for some
time, until I noticed that:
--- a/src/bin/pg_dump/pg_dump.c
+++ b/src/bin/pg_dump/pg_dump.c
@@ -15671,7 +15671,7 @@ dumpSequenceData(Archive *fout, TableDataInfo *tdinfo)
appendPQExpBuffer(query, ", %s, %s);\n",
last, (called ? "true" : "false"));
- if (tbinfo->dobj.dump & DUMP_COMPONENT_DATA)
+ if (tdinfo->dobj.dump & DUMP_COMPONENT_DATA)
ArchiveEntry(fout, nilCatalogId, createDumpId(),
tbinfo->dobj.name,
tbinfo->dobj.namespace->dobj.name,
Not sure if I need to laugh or cry. Attached is a patch with the fix
and new regression tests.
--
Michael
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
