Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
>> No, just remove the RELKIND_UNCATALOGUED case in that switch.
> Oh. As in the attached? :)
I don't think you tested this patch in 9.2 or HEAD, because it bleats
like mad. I installed an extension containing
create sequence extseq;
select pg_catalog.pg_extension_config_dump('extseq', '');
into the regression database, and then did:
$ pg_dump -Fc regression >r.dump
pg_dump: [archiver] WARNING: archive items not in correct section order
pg_dump: [archiver] WARNING: archive items not in correct section order
pg_dump: [archiver] WARNING: archive items not in correct section order
pg_dump: [archiver] WARNING: archive items not in correct section order
pg_dump: [archiver] WARNING: archive items not in correct section order
pg_dump: [archiver] WARNING: archive items not in correct section order
pg_dump: [archiver] WARNING: archive items not in correct section order
pg_dump: [archiver] WARNING: archive items not in correct section order
The reason is that it calls dumpSequence() to emit the SEQUENCE SET
archive item during table-data dumping, but the archive item gets marked
SECTION_PRE_DATA. As of 9.2 we have to be rigid about keeping those
section markings correct and in-sequence. This is not really right in
9.1 either (wouldn't be surprised if it breaks parallel restore).
The fact that SEQUENCE SET is considered pre-data has bitten us several
times already, eg
http://archives.postgresql.org/pgsql-bugs/2012-05/msg00084.php
I think it may be time to bite the bullet and change that (including
breaking dumpSequence() into two separate functions). I'm a little bit
worried about the compatibility implications of back-patching such a
change, though. Is it likely that anybody out there is depending on the
fact that, eg, pg_dump --section=pre-data currently includes SEQUENCE SET
items? Personally I think it's more likely that that'd be seen as a
bug, but ...
regards, tom lane
