Re: [HACKERS] sequences and pg_upgrade

2016-11-13 Thread Peter Eisentraut
On 11/2/16 2:34 AM, Michael Paquier wrote: > I had a look at those fresh patches, and 0001 looks like a good thing. > This makes the separation between sequences and table data dump > cleaner. I ran some tests with pg_upgrade and 0002, and things are > clear. And +1 for the way done in the patch,

Re: [HACKERS] sequences and pg_upgrade

2016-11-02 Thread Michael Paquier
On Mon, Oct 31, 2016 at 9:53 PM, Peter Eisentraut wrote: > On 9/30/16 12:50 PM, Anastasia Lubennikova wrote: >> The patches are good, no complaints. >> But again, I have the same question. >> I was confused, why do we always dump sequence data, >> because I'd

Re: [HACKERS] sequences and pg_upgrade

2016-10-31 Thread Peter Eisentraut
On 9/30/16 12:50 PM, Anastasia Lubennikova wrote: > The patches are good, no complaints. > But again, I have the same question. > I was confused, why do we always dump sequence data, > because I'd overlooked the --sequence-data key. I'd rather leave this > option, > because it's quite non

Re: [HACKERS] sequences and pg_upgrade

2016-10-02 Thread Michael Paquier
On Sat, Oct 1, 2016 at 1:50 AM, Anastasia Lubennikova wrote: > 23.09.2016 21:06, Peter Eisentraut: >> >> Here is an updated patch set. Compared to the initial set, I have >> changed pg_dump's sorting priorities so that sequence data is always >> after table data.

Re: [HACKERS] sequences and pg_upgrade

2016-09-30 Thread Anastasia Lubennikova
23.09.2016 21:06, Peter Eisentraut: Here is an updated patch set. Compared to the initial set, I have changed pg_dump's sorting priorities so that sequence data is always after table data. This would otherwise have introduced a problem because sortDataAndIndexObjectsBySize() only considers

Re: [HACKERS] sequences and pg_upgrade

2016-09-23 Thread Peter Eisentraut
Here is an updated patch set. Compared to the initial set, I have changed pg_dump's sorting priorities so that sequence data is always after table data. This would otherwise have introduced a problem because sortDataAndIndexObjectsBySize() only considers consecutive DO_TABLE_DATA entries. Also,

Re: [HACKERS] sequences and pg_upgrade

2016-09-15 Thread Anastasia Lubennikova
15.09.2016 15:29, Peter Eisentraut: On 9/14/16 8:52 AM, Anastasia Lubennikova wrote: Could you clarify, please, why do we dump sequence in schemaOnly mode? + if (dopt.schemaOnly && dopt.sequence_data) + getSequenceData(, tblinfo, numTables, dopt.oids); The point of this

Re: [HACKERS] sequences and pg_upgrade

2016-09-15 Thread Peter Eisentraut
On 9/14/16 8:52 AM, Anastasia Lubennikova wrote: > Could you clarify, please, why do we dump sequence in schemaOnly mode? > + if (dopt.schemaOnly && dopt.sequence_data) > + getSequenceData(, tblinfo, numTables, dopt.oids); The point of this patch is that with the new option, you

Re: [HACKERS] sequences and pg_upgrade

2016-09-14 Thread Anastasia Lubennikova
The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, failed Thank you for the patch. As I see there are no objections in

Re: [HACKERS] sequences and pg_upgrade

2016-08-30 Thread Andres Freund
On 2016-08-30 08:46:48 -0400, Peter Eisentraut wrote: > I was toying with a couple of ideas that would involve changing the > storage of sequences. (Say, for the sake of discussion, removing the > problematic/useless sequence_name field.) I'd be quite interested to know what changes that are...

Re: [HACKERS] sequences and pg_upgrade

2016-08-30 Thread Bruce Momjian
On Tue, Aug 30, 2016 at 08:46:48AM -0400, Peter Eisentraut wrote: > I think the other solution mentioned in that thread would also work: > Have pg_upgrade treat sequences more like system catalogs, whose format > changes between major releases, and transferred them via the > dump/restore route.

Re: [HACKERS] sequences and pg_upgrade

2016-08-30 Thread Tom Lane
Peter Eisentraut writes: > I was toying with a couple of ideas that would involve changing the > storage of sequences. (Say, for the sake of discussion, removing the > problematic/useless sequence_name field.) This would cause problems for > pg_upgrade, because