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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Martin Pitt <mpitt(at)debian(dot)org>, PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Re: 9.2beta1 regression: pg_restore --data-only does not set sequence values any more
Date: 2012-05-29 22:05:25
Message-ID: 426.1338329125@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>>> Martin Pitt <mpitt(at)debian(dot)org <mailto:mpitt(at)debian(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Bruce Momjian 2012-05-30 00:44:07 Re: BUG #6666: pg_upgrade 9.2beta1 plpython/plpython2
Previous Message Robert Haas 2012-05-29 17:40:08 Re: pg_dump: SQL command failed

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Dilger 2012-05-29 22:28:48 Re: Performance patch for Win32
Previous Message Bruce Momjian 2012-05-29 21:48:00 Re: pg_upgrade libraries check