From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | Daniel Verite <daniel(at)manitou-mail(dot)org>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Off-by-one oddity in minval for decreasing sequences |
Date: | 2017-01-21 03:08:40 |
Message-ID: | CAB7nPqRNOK+ZUNS8MM3NsgdSMuKW5BmsT_o-4SWDKWDsi2x94w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jan 21, 2017 at 10:20 AM, Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> On 1/6/17 2:15 PM, Daniel Verite wrote:
>> I notice that there's a preexisting
>> oddity in the fact that sequences created with a negative increment
>> in current releases initialize the minval to -(2^63)+1 instead of -2^63,
>> the actual lowest value for a bigint.
>
> I think that had to do with that we had to play games to work around the
> lack of proper int64 support, and various weird code has developed over
> time because of that. I think we should fix it if we can.
>
> The attached patch fixes the default minimum value to use the proper
> int64 min value.
>
> With this patch, when upgrading with pg_dump, descending sequences with
> the previous default minimum value would be kept with that
> now-not-default value. We could alternative adjust those sequences to
> the new default value.
This patch looks acceptable to me.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2017-01-21 04:12:15 | Re: Packages: Again |
Previous Message | Thomas Munro | 2017-01-21 01:49:48 | Re: Measuring replay lag |