retroactive pg10 relnotes: sequence changes

Started by Alvaro Herreraover 7 years ago6 messagesdocs
Jump to latest
#1Alvaro Herrera
alvherre@2ndquadrant.com

Hello

A customer of ours was taken by surprise by a change in Postgres 10 on a
trial upgrade from 9.6. They were using sequences from SERIAL columns a
little unorthodoxly, and their stuff stopped working: essentially, they
hacked the default expression so that it'd automatically use negative
numbers when the sequence reached INT_MAX. Since pg10 changed sequences
to stop emitting values at that point, it raised an error rather than
emit the negative numbers.

(In 9.6 and prior, the sequence would emit values past INT_MAX; it was
the column that raised the error. In pg10 things were changed so that
it is now the sequence that raises the error.)

My proposal now is to document this issue in the Postgres 10 release
notes. "It's a little late for that!" I hear you say, but keep this in
mind: many users have *not* yet upgraded to 10, and they'll keep doing
it for years to come still. So I disagree that now is too late. We
failed to warn people that already upgraded, but we're still on time to
alert people yet to upgrade.

I attach both the patch and a screenshot to show how minor the visual
effect of the change is.

(If people hate this, another option is to make it a separate bullet
point.)

--
�lvaro Herrera

Attachments:

sequences-10.patchtext/plain; charset=us-asciiDownload+7-0
sequences.pngimage/pngDownload+0-1
#2Magnus Hagander
magnus@hagander.net
In reply to: Alvaro Herrera (#1)
Re: retroactive pg10 relnotes: sequence changes

On Tue, Aug 28, 2018 at 6:34 PM, Alvaro Herrera <alvherre@2ndquadrant.com>
wrote:

Hello

A customer of ours was taken by surprise by a change in Postgres 10 on a
trial upgrade from 9.6. They were using sequences from SERIAL columns a
little unorthodoxly, and their stuff stopped working: essentially, they
hacked the default expression so that it'd automatically use negative
numbers when the sequence reached INT_MAX. Since pg10 changed sequences
to stop emitting values at that point, it raised an error rather than
emit the negative numbers.

(In 9.6 and prior, the sequence would emit values past INT_MAX; it was
the column that raised the error. In pg10 things were changed so that
it is now the sequence that raises the error.)

My proposal now is to document this issue in the Postgres 10 release
notes. "It's a little late for that!" I hear you say, but keep this in
mind: many users have *not* yet upgraded to 10, and they'll keep doing
it for years to come still. So I disagree that now is too late. We
failed to warn people that already upgraded, but we're still on time to
alert people yet to upgrade.

I attach both the patch and a screenshot to show how minor the visual
effect of the change is.

(If people hate this, another option is to make it a separate bullet
point.)

Looks reasonable to me. And I definitely think we should do it -- people
will be upgrading to 10 for years to come, so claiming it's too late is
definitely not correct.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/&gt;
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/&gt;

#3Jonathan S. Katz
jkatz@postgresql.org
In reply to: Magnus Hagander (#2)
Re: retroactive pg10 relnotes: sequence changes

On Aug 28, 2018, at 1:02 PM, Magnus Hagander <magnus@hagander.net> wrote:

On Tue, Aug 28, 2018 at 6:34 PM, Alvaro Herrera <alvherre@2ndquadrant.com <mailto:alvherre@2ndquadrant.com>> wrote:
Hello

A customer of ours was taken by surprise by a change in Postgres 10 on a
trial upgrade from 9.6. They were using sequences from SERIAL columns a
little unorthodoxly, and their stuff stopped working: essentially, they
hacked the default expression so that it'd automatically use negative
numbers when the sequence reached INT_MAX. Since pg10 changed sequences
to stop emitting values at that point, it raised an error rather than
emit the negative numbers.

(In 9.6 and prior, the sequence would emit values past INT_MAX; it was
the column that raised the error. In pg10 things were changed so that
it is now the sequence that raises the error.)

My proposal now is to document this issue in the Postgres 10 release
notes. "It's a little late for that!" I hear you say, but keep this in
mind: many users have *not* yet upgraded to 10, and they'll keep doing
it for years to come still. So I disagree that now is too late. We
failed to warn people that already upgraded, but we're still on time to
alert people yet to upgrade.

I attach both the patch and a screenshot to show how minor the visual
effect of the change is.

(If people hate this, another option is to make it a separate bullet
point.)

Looks reasonable to me. And I definitely think we should do it -- people will be upgrading to 10 for years to come, so claiming it's too late is definitely not correct.

+1.

I have attached patch where I suggested some alternate wording and
remove the parenthetical comment, as I don’t believe that should be
an aside.

Jonathan

Attachments:

sequences-10.patchapplication/octet-stream; name=sequences-10.patch; x-unix-mode=0644Download+7-0
#4Jonathan S. Katz
jkatz@postgresql.org
In reply to: Jonathan S. Katz (#3)
Re: retroactive pg10 relnotes: sequence changes

On Aug 28, 2018, at 1:09 PM, Jonathan S. Katz <jkatz@postgresql.org> wrote:

On Aug 28, 2018, at 1:02 PM, Magnus Hagander <magnus@hagander.net <mailto:magnus@hagander.net>> wrote:

On Tue, Aug 28, 2018 at 6:34 PM, Alvaro Herrera <alvherre@2ndquadrant.com <mailto:alvherre@2ndquadrant.com>> wrote:
Hello

A customer of ours was taken by surprise by a change in Postgres 10 on a
trial upgrade from 9.6. They were using sequences from SERIAL columns a
little unorthodoxly, and their stuff stopped working: essentially, they
hacked the default expression so that it'd automatically use negative
numbers when the sequence reached INT_MAX. Since pg10 changed sequences
to stop emitting values at that point, it raised an error rather than
emit the negative numbers.

(In 9.6 and prior, the sequence would emit values past INT_MAX; it was
the column that raised the error. In pg10 things were changed so that
it is now the sequence that raises the error.)

My proposal now is to document this issue in the Postgres 10 release
notes. "It's a little late for that!" I hear you say, but keep this in
mind: many users have *not* yet upgraded to 10, and they'll keep doing
it for years to come still. So I disagree that now is too late. We
failed to warn people that already upgraded, but we're still on time to
alert people yet to upgrade.

I attach both the patch and a screenshot to show how minor the visual
effect of the change is.

(If people hate this, another option is to make it a separate bullet
point.)

Looks reasonable to me. And I definitely think we should do it -- people will be upgrading to 10 for years to come, so claiming it's too late is definitely not correct.

+1.

I have attached patch where I suggested some alternate wording and
remove the parenthetical comment, as I don’t believe that should be
an aside.

Per off-list discussion from Bruce, re-attaching the patch. Apparently
it was only available in HTML mimepart. Hopefully this gets it into
the archives.

Jonathan

Attachments:

sequences-10-v2.patchapplication/octet-stream; name=sequences-10-v2.patch; x-unix-mode=0644Download+7-0
#5Andres Freund
andres@anarazel.de
In reply to: Magnus Hagander (#2)
Re: retroactive pg10 relnotes: sequence changes

On 2018-08-28 19:02:06 +0200, Magnus Hagander wrote:

Looks reasonable to me. And I definitely think we should do it -- people
will be upgrading to 10 for years to come, so claiming it's too late is
definitely not correct.

Please make sure to backpatch it to all branches carrying v10 release
notes...

Greetings,

Andres Freund

#6Alvaro Herrera
alvherre@2ndquadrant.com
In reply to: Jonathan S. Katz (#3)
Re: retroactive pg10 relnotes: sequence changes

On 2018-Aug-28, Jonathan S. Katz wrote:

I have attached patch where I suggested some alternate wording and
remove the parenthetical comment, as I don’t believe that should be
an aside.

Cool, thanks. I have pushed it with your proposed wording.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services