Re: [HACKERS] Re: 9.2beta1 regression: pg_restore --data-only does not set sequence values any more
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Re: 9.2beta1 regression: pg_restore --data-only does not set sequence values any more |
Дата | |
Msg-id | 426.1338329125@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: 9.2beta1 regression: pg_restore --data-only does not set sequence values any more (Andrew Dunstan <andrew@dunslane.net>) |
Список | 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 по дате отправления: