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
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 |
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 |