Thread: initial random incompatibility
Hi,
While fixing the breakage caused by the default number of trailing
digits output for real and double precision, I noticed that first
random() call after setseed(0) doesn't return the same value as 10 and
earlier (I tested 9.4 and later). It changed an expected behavior and
it should be listed in incompatibilities section of the release notes.
Some applications can rely on such behavior.
$ psql postgres
psql (10.4)
Type "help" for help.
postgres=# select setseed(0);
setseed
---------
(1 row)
postgres=# select random();
random
-------------------
0.840187716763467
(1 row)
$ psql postgres
psql (12beta1)
Type "help" for help.
postgres=# select setseed(0);
setseed
---------
(1 row)
postgres=# select random();
random
-----------------------
3.907985046680551e-14
(1 row)
It seems related to the pg_erand48() adoption at the end of the year
[1] (commit 6645ad6bdd81e7d5a764e0d94ef52fae053a9e13).
[1] https://www.postgresql.org/message-id/3859.1545849900@sss.pgh.pa.us
--
Euler Taveira Timbira -
http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
On 2019-Jun-08, Euler Taveira wrote: > While fixing the breakage caused by the default number of trailing > digits output for real and double precision, I noticed that first > random() call after setseed(0) doesn't return the same value as 10 and > earlier (I tested 9.4 and later). It changed an expected behavior and > it should be listed in incompatibilities section of the release notes. > Some applications can rely on such behavior. Hmm. Tom argued about the backwards-compatibility argument in the discussion that led to that commit: https://www.postgresql.org/message-id/3859.1545849900@sss.pgh.pa.us I think this is worth listing in the release notes. Can you propose some wording? -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
I cannot find traces, but I believe there was a Twitter poll on which random do people get after setseed() in postgres, and we found at least three distinct sequences across different builds.
On Mon, Jun 10, 2019 at 5:52 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
On 2019-Jun-08, Euler Taveira wrote:
> While fixing the breakage caused by the default number of trailing
> digits output for real and double precision, I noticed that first
> random() call after setseed(0) doesn't return the same value as 10 and
> earlier (I tested 9.4 and later). It changed an expected behavior and
> it should be listed in incompatibilities section of the release notes.
> Some applications can rely on such behavior.
Hmm. Tom argued about the backwards-compatibility argument in
the discussion that led to that commit:
https://www.postgresql.org/message-id/3859.1545849900@sss.pgh.pa.us
I think this is worth listing in the release notes. Can you propose
some wording?
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Darafei Praliaskouski
Support me: http://patreon.com/komzpa
On 2019-Jun-17, Darafei "Komяpa" Praliaskouski wrote: > I cannot find traces, but I believe there was a Twitter poll on which > random do people get after setseed() in postgres, and we found at least > three distinct sequences across different builds. In different machines or different build options? I suppose that's acceptable ... the problem is changing the sequence in one release to the next in the same machine with the same build options. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> On 2019-Jun-17, Darafei "Komяpa" Praliaskouski wrote:
>> I cannot find traces, but I believe there was a Twitter poll on which
>> random do people get after setseed() in postgres, and we found at least
>> three distinct sequences across different builds.
> In different machines or different build options? I suppose that's
> acceptable ... the problem is changing the sequence in one release to
> the next in the same machine with the same build options.
FWIW, I agree that this change should be called out as a possible
compatibility hazard, even though anybody who was expecting repeatable
behavior from the old code was playing with fire.
regards, tom lane