Re: [HACKERS] Re: 9.2beta1 regression: pg_restore --data-only does not set sequence values any more - Mailing list pgsql-bugs

From Tom Lane
Subject Re: [HACKERS] Re: 9.2beta1 regression: pg_restore --data-only does not set sequence values any more
Date
Msg-id 426.1338329125@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Re: 9.2beta1 regression: pg_restore --data-only does not set sequence values any more  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-bugs
Andrew Dunstan <andrew@dunslane.net> writes:
>>> Martin Pitt <mpitt@debian.org <mailto:mpitt@debian.org>> writes:
>>>> while packaging 9.2 beta 1 for Debian/Ubuntu the postgresql-common
>>>> test suite noticed a regression: It seems that pg_restore --data-only
>>>> now skips the current value of sequences, so that in the upgraded
>>>> database the sequence counter is back to the default.

> It turns out there were some infelicities with pg_dump as well as with 
> pg_restore.

> I think the attached patch does the right thing. I'll keep testing - 
> I'll be happier if other people bang on it too.

After looking this over, I think the original patch was just
fundamentally wrong and needs to be largely rewritten.  The basic
error was in saying that the existing options --schema-only and
--data-only were equivalent to particular cases of --section, which
they are not.  The proposed new patch does not make this better;
it just makes the logic even more spaghetti-ish.

I think what we need is to rip all that out and treat --section as being
a new option that's not tied to the old ones in any way, but is an
entirely orthogonal filter.  The right place to implement it (for either
pg_dump or pg_restore) is in the TOC-scanning loops in
pg_backup_archiver.c, which can track which section they are in fairly
easily (probably define it as being the current item's section unless
that's SECTION_NONE, in which case use the previous section value).

BTW, I'm thinking we could make that code simpler and faster if the
_tocEntryRequired logic were done only once in an initial pass, and then
we stored the teReqs result into a work field in the TocEntry struct
for use in later passes.

Andrew told me off-list that he would be unavailable due to travel for
awhile, so I will have a go at fixing this.
        regards, tom lane


pgsql-bugs by date:

Previous
From: Robert Haas
Date:
Subject: Re: pg_dump: SQL command failed
Next
From: Bruce Momjian
Date:
Subject: Re: BUG #6666: pg_upgrade 9.2beta1 plpython/plpython2