Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fuhUT-0002Y1-D4 for pgsql-docs@arkaria.postgresql.org; Tue, 28 Aug 2018 17:09:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fuhUQ-0002Iv-Qk for pgsql-docs@arkaria.postgresql.org; Tue, 28 Aug 2018 17:09:14 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fuhUQ-0002Io-Hh for pgsql-docs@lists.postgresql.org; Tue, 28 Aug 2018 17:09:14 +0000 Received: from meldrar.postgresql.org ([2a02:c0:301:0:ffff::31]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fuhUN-0003C1-AW for pgsql-docs@postgresql.org; Tue, 28 Aug 2018 17:09:13 +0000 Received: from [144.121.72.194] (helo=[172.16.7.107]) by meldrar.postgresql.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fuhUI-0006YP-4j; Tue, 28 Aug 2018 17:09:09 +0000 From: "Jonathan S. Katz" Message-Id: <006E0E48-7E9C-4C34-9BCA-C51C2076E3B9@postgresql.org> Content-Type: multipart/signed; boundary="Apple-Mail=_D2CD2304-D211-41AA-80AA-BFA3E8E2CACE"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: retroactive pg10 relnotes: sequence changes Date: Tue, 28 Aug 2018 13:09:01 -0400 In-Reply-To: Cc: Alvaro Herrera , Pg Docs To: Magnus Hagander References: <20180828163408.vl44nwetdybwffyk@alvherre.pgsql> X-Mailer: Apple Mail (2.3273) X-Host-Lookup-Failed: Reverse DNS lookup failed for 144.121.72.194 (failed) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --Apple-Mail=_D2CD2304-D211-41AA-80AA-BFA3E8E2CACE Content-Type: multipart/alternative; boundary="Apple-Mail=_EC222428-DD56-4495-8E6E-5F1DE73FDB5F" --Apple-Mail=_EC222428-DD56-4495-8E6E-5F1DE73FDB5F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 28, 2018, at 1:02 PM, Magnus Hagander = wrote: >=20 >=20 >=20 > On Tue, Aug 28, 2018 at 6:34 PM, Alvaro Herrera = > wrote: > Hello >=20 > 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. >=20 > (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.) >=20 > 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. >=20 > I attach both the patch and a screenshot to show how minor the visual > effect of the change is. >=20 > (If people hate this, another option is to make it a separate bullet > point.) >=20 > 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=E2=80=99t believe that should = be an aside. Jonathan --Apple-Mail=_EC222428-DD56-4495-8E6E-5F1DE73FDB5F Content-Type: multipart/mixed; boundary="Apple-Mail=_572E63B9-7953-456A-ACF5-D3806613FCD3" --Apple-Mail=_572E63B9-7953-456A-ACF5-D3806613FCD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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> 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=E2=80=99t = believe that should be
an aside.

Jonathan

= --Apple-Mail=_572E63B9-7953-456A-ACF5-D3806613FCD3 Content-Disposition: attachment; filename=sequences-10.patch Content-Type: application/octet-stream; x-unix-mode=0644; name="sequences-10.patch" Content-Transfer-Encoding: 7bit diff --git a/doc/src/sgml/release-10.sgml b/doc/src/sgml/release-10.sgml index f1b0f2e0bf..09e5d0c593 100644 --- a/doc/src/sgml/release-10.sgml +++ b/doc/src/sgml/release-10.sgml @@ -4716,6 +4716,13 @@ Branch: REL_10_STABLE [5159626af] 2017-11-03 14:14:16 -0400 more compatible with existing code. + + Also, sequences created for SERIAL columns now generate + positive 32-bit wide values, whereas previous versions generated 64-bit + wide values. This has no visible effect if the values are only stored in + a column. + + The output of psql's \d command for a sequence has been redesigned, too. --Apple-Mail=_572E63B9-7953-456A-ACF5-D3806613FCD3 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

--Apple-Mail=_572E63B9-7953-456A-ACF5-D3806613FCD3-- --Apple-Mail=_EC222428-DD56-4495-8E6E-5F1DE73FDB5F-- --Apple-Mail=_D2CD2304-D211-41AA-80AA-BFA3E8E2CACE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE+oS2la8r95ogZD/x8QSccp8cZScFAluFga0ACgkQ8QSccp8c ZSfHOxAAjyrSwaT+6aChAZ9LCZJlvkGTk4WSdZLCA9WbPaIdosjNTJ993TCUU+7P Q3Mfv7n5xVxX0i0iuLwWbQoDMSye7l2tGPyjbVSw/UuIxd4VDTimoNJQY+5ASKAp eGEaPngEObxVM4rF2mmwAw6N1VsLFWDEqW2P5p0RCsh9P4/DhnythnExWR431K5U QsFl/GxzvE5GKti9ywg00VmuMGXFYr7iSgr8gG6iIjKHoV3KzSrojC5KAHSMG3FF iNo8IwE1H7AM5I8Cvx3T8yege5J19nBkarFzzHYX4u+K8XaKufLJeHGlWJ1iSuX3 jU8yhr0F5DfEpsgSCTqbUDUoGWN1dhlJ9SLbDAfTUwZFbZh0Hd9TV8ABTv3vIhzy f+HndOYDcQODGJz+WtpO1RNXaCvwqxTsgagyegCaettjy8vz2uoc7/Oi9DuMlD1z /1/eOKCun3M4a3uuzf/50hHUVkFo4zScUpPOs47iS6bjFRXA0E9ll4VTUmdrNF7U +/mFvrvxXz7NZ5ZiMb7nAnS8bCiv7OR4O9IPC3GJehavKKDAEoCeslC6wk+XWGXG h2G1jT6kbtg5T5lQD75BgOJWp/g7BH4GZbQA8UOqCJk1eM6H5ajG1zcq47AITFQv /Hi5QsiguJ3Nzc+Wy12+UxENK9rdQE08/rLKOUaC0WqRpmFpM+I= =E20s -----END PGP SIGNATURE----- --Apple-Mail=_D2CD2304-D211-41AA-80AA-BFA3E8E2CACE--