Dump sequence data based on the TableDataInfo flag
authorStephen Frost <sfrost@snowman.net>
Thu, 19 Jan 2017 17:06:21 +0000 (12:06 -0500)
committerStephen Frost <sfrost@snowman.net>
Thu, 19 Jan 2017 17:06:21 +0000 (12:06 -0500)
When considering a sequence's Data entry in dumpSequenceData, we were
actually looking at the sequence definition's dump flag to decide if we
should dump the data or not.  That's generally fine, except for when the
sequence data entry was created by processExtensionTables() because it's
a config sequence.  In that case, the sequence itself won't be marked as
dumping data because it's part of an extension, leading to the need for
processExtensionTables() to create the sequence data entry.

This leads to extension config sequence data not being included in the
dump when it should be.  Fix this by looking at the sequence data's dump
flag instead, just as dumpTableData() was doing for tables (which is why
config tables were correctly being handled), and add a regression test
to make sure we don't break it moving forward.

All of this is a bit round-about since we can now represent which
components of a given dump item should be dumped out through the dump
flag.  A future improvement might be to change checkExtensionMembership()
to check for config sequences/tables and set the dump flag based on that
directly, possibly removing the need for processExtensionTables().

Bug found by Daniele Varrazzo.

Discussion: https://postgr.es/m/CA+mi_8ZmxQM7+nZ7pJ8uyfxc9V3o=UAG14dVqvftdmvw8OJ3gQ@mail.gmail.com

Patch by Michael Paquier, with some tweaking of the regression tests by
me.

Back-patch to 9.6 where the bug was introduced.

src/bin/pg_dump/pg_dump.c
src/test/modules/test_pg_dump/t/001_base.pl
src/test/modules/test_pg_dump/test_pg_dump--1.0.sql

index 1f3f019506cafa8dc05bdad91a5260a26b49dda1..883fde1e5aa213c04cc94637addb1aec3f347c15 100644 (file)
@@ -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,
index dc90a4aa12f49d72309e81dd965a03400e8d9a98..70719a36a7ea48facf5d9158203b255fc20cc733 100644 (file)
@@ -265,6 +265,25 @@ my %tests = (
            schema_only        => 1,
            section_pre_data   => 1,
            section_post_data  => 1, }, },
+   'SETVAL SEQUENCE regress_seq_dumpable' => {
+       create_order => 6,
+       create_sql => qq{SELECT nextval('regress_seq_dumpable');},
+       regexp => qr/^
+           \QSELECT pg_catalog.setval('regress_seq_dumpable', 1, true);\E
+           \n/xm,
+       like   => {
+           clean              => 1,
+           clean_if_exists    => 1,
+           createdb           => 1,
+           data_only          => 1,
+           defaults           => 1,
+           no_owner           => 1,
+           no_privs           => 1, },
+       unlike => {
+           pg_dumpall_globals => 1,
+           schema_only        => 1,
+           section_pre_data   => 1,
+           section_post_data  => 1, }, },
    'CREATE TABLE regress_pg_dump_table' => {
        regexp => qr/^
            \QCREATE TABLE regress_pg_dump_table (\E
index ca9fb18e5408e466c268aaea3ac7ce1d88fa3eb3..3ed007a7b1b4190f269d34dc4a59af9f7ada39bf 100644 (file)
@@ -10,6 +10,9 @@ CREATE TABLE regress_pg_dump_table (
 
 CREATE SEQUENCE regress_pg_dump_seq;
 
+CREATE SEQUENCE regress_seq_dumpable;
+SELECT pg_catalog.pg_extension_config_dump('regress_seq_dumpable', '');
+
 CREATE SCHEMA regress_pg_dump_schema;
 
 GRANT USAGE ON regress_pg_dump_seq TO regress_dump_test_role;