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, a
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 overlooked the --sequence-data key. I'
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 intuitiv
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. This would otherwise have introd
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 cons
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,
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(&dopt, tblinfo, numTables, dopt.oids);
The point of this
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(&dopt, tblinfo, numTables, dopt.oids);
The point of this patch is that with the new option, y
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
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...
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. So
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 pg_upgrade copies the "heap" stora
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 pg_upgrade copies the "heap" storage of sequences
like it does for n
13 matches
Mail list logo