Thread: numeric regression test passes, but why?
I see there are some tests in src/test/regress: sql/numeric.sql expected/numeric.out They pass. I see "numeric ... ok" in a make check. I do not doubt they are being run, because if I edit numeric.sql and fudge some digits, say around -- cases that used to error out select 0.12 ^ (-25); select 0.5678 ^ (-85); and I change the -25 to -26, numeric then fails in my next make check. All that seems just as it should be. Why, then, if I try to duplicate those exact tests in an interactive session, would this happen: postgres=# select 0.12 ^ (-25); ERROR: division by zero STATEMENT: select 0.12 ^ (-25); postgres=# select 0.5678 ^ (-85); ERROR: division by zero STATEMENT: select 0.5678 ^ (-85); ... they error out, that is, do exactly the thing the tests are there to make sure they do not. Is there some special GUC setting in effect during the make check that would be different in my ordinary session? What else could be different? This is making me question my sanity. -Chap
Chapman Flack <chap@anastigmatix.net> writes:
> I see there are some tests in src/test/regress:
> [ that don't work for me ]
> Is there some special GUC setting in effect during the make check
> that would be different in my ordinary session? What else could
> be different? This is making me question my sanity.
Hm, it won't help your sanity to know that those cases pass fine
for me, interactively, on a couple of different machines:
$ psql postgres
psql (11devel)
Type "help" for help.
postgres=# select 0.12 ^ (-25);
?column?
-------------------------------------------
104825960103961013959336.4983657883169110
(1 row)
postgres=# select 0.5678 ^ (-85);
?column?
----------------------------------------
782333637740774446257.7719390061997396
(1 row)
You sure you're using a stock build of Postgres? No handmade
versions of operator ^ lying around?
regards, tom lane
On 01/11/18 02:07, Tom Lane wrote: > Hm, it won't help your sanity to know that those cases pass fine > for me, interactively, on a couple of different machines: > ... > You sure you're using a stock build of Postgres? No handmade > versions of operator ^ lying around? Interesting thought.... At $work: postgresql95-server.x86_64 9.5.10-1PGDG.rhel7 @pgdg95 postgres=> select 0.5678 operator(pg_catalog.^) (-85); ERROR: division by zero postgres=> select 0.5678::numeric operator(pg_catalog.^) (-85::numeric); ERROR: division by zero Also at home in a gentoo 9.5.1 ebuild... Also in a build from e35dba475a440f73dccf9ed1fd61e3abc6ee61db in git. All x86_64 .... -Chap
Re: numeric regression test passes, but why?
From
ilmari@ilmari.org (Dagfinn Ilmari Mannsåker)
Date:
Tom Lane <tgl@sss.pgh.pa.us> writes: > Chapman Flack <chap@anastigmatix.net> writes: >> I see there are some tests in src/test/regress: >> [ that don't work for me ] >> Is there some special GUC setting in effect during the make check >> that would be different in my ordinary session? What else could >> be different? This is making me question my sanity. > > Hm, it won't help your sanity to know that those cases pass fine > for me, interactively, on a couple of different machines: > > $ psql postgres > psql (11devel) > Type "help" for help. > > postgres=# select 0.12 ^ (-25); > ?column? > ------------------------------------------- > 104825960103961013959336.4983657883169110 > (1 row) > > postgres=# select 0.5678 ^ (-85); > ?column? > ---------------------------------------- > 782333637740774446257.7719390061997396 > (1 row) > > You sure you're using a stock build of Postgres? No handmade > versions of operator ^ lying around? The behaviour seems to have changed in 9.6: $ psql -p5495 Line style is unicode. Border style is 2. psql (10.1, server 9.5.10) Type "help" for help. ilmari@[local]:5495 ~=# select 0.12 ^ (-25); ERROR: division by zero ilmari@[local]:5495 ~=# \q $ psql -p5496 Line style is unicode. Border style is 2. psql (10.1, server 9.6.6) Type "help" for help. ilmari@[local]:5496 ~=# select 0.12 ^ (-25); ┌───────────────────────────────────────────┐ │ ?column? │ ├───────────────────────────────────────────┤ │ 104825960103961013959336.4983657883169110 │ └───────────────────────────────────────────┘ (1 row) ilmari@[local]:5496 ~=# \q - ilmari -- "A disappointingly low fraction of the human race is, at any given time, on fire." - Stig Sandbeck Mathisen
Hello I am surprised, but i can confirm error on versions prior 9.6: on 9.5, 9.4, 9.3 same error. On 9.6 and 10 query works correctly All checked postgresql are x86_64 from postgresql debian repository: http://apt.postgresql.org/pub/repos/apt/ jessie-pgdgmain postgres=# select 0.5678::numeric operator(pg_catalog.^) (-85::numeric); ERROR: division by zero postgres=# select version(); version ------------------------------------------------------------------------------------------- PostgreSQL 9.5.10 on x86_64-pc-linux-gnu, compiled by gcc (Debian 4.9.2-10) 4.9.2, 64-bit Regards, Sergei 11.01.2018, 15:27, "Chapman Flack" <chap@anastigmatix.net>: > On 01/11/18 02:07, Tom Lane wrote: > >> Hm, it won't help your sanity to know that those cases pass fine >> for me, interactively, on a couple of different machines: >> ... >> You sure you're using a stock build of Postgres? No handmade >> versions of operator ^ lying around? > > Interesting thought.... > > At $work: > postgresql95-server.x86_64 9.5.10-1PGDG.rhel7 @pgdg95 > > postgres=> select 0.5678 operator(pg_catalog.^) (-85); > ERROR: division by zero > postgres=> select 0.5678::numeric operator(pg_catalog.^) (-85::numeric); > ERROR: division by zero > > Also at home in a gentoo 9.5.1 ebuild... > Also in a build from e35dba475a440f73dccf9ed1fd61e3abc6ee61db in git. > > All x86_64 .... > > -Chap
Re: numeric regression test passes, but why?
From
ilmari@ilmari.org (Dagfinn Ilmari Mannsåker)
Date:
ilmari@ilmari.org (Dagfinn Ilmari Mannsåker) writes: > The behaviour seems to have changed in 9.6: Indeed, https://www.postgresql.org/docs/current/static/release-9-6.html has the following entry: * Improve the accuracy of the ln(), log(), exp(), and pow() functions for type numeric (Dean Rasheed) > $ psql -p5495 > Line style is unicode. > Border style is 2. > psql (10.1, server 9.5.10) > Type "help" for help. > > ilmari@[local]:5495 ~=# select 0.12 ^ (-25); > ERROR: division by zero > ilmari@[local]:5495 ~=# \q > > $ psql -p5496 > Line style is unicode. > Border style is 2. > psql (10.1, server 9.6.6) > Type "help" for help. > > ilmari@[local]:5496 ~=# select 0.12 ^ (-25); > ┌───────────────────────────────────────────┐ > │ ?column? │ > ├───────────────────────────────────────────┤ > │ 104825960103961013959336.4983657883169110 │ > └───────────────────────────────────────────┘ > (1 row) > > ilmari@[local]:5496 ~=# \q > > - ilmari -- "A disappointingly low fraction of the human race is, at any given time, on fire." - Stig Sandbeck Mathisen
On 01/11/2018 07:44 AM, Sergei Kornilov wrote: > Hello > I am surprised, but i can confirm error on versions prior 9.6: on 9.5, 9.4, 9.3 same error. On 9.6 and 10 query works correctly One of my tests (in fact, the one where I first noticed) was a build from git a couple days ago at e35dba475a440f73dccf9ed1fd61e3abc6ee61db though. -Chap
Dagfinn Ilmari Mannsåker wrote: > ilmari@ilmari.org (Dagfinn Ilmari Mannsåker) writes: > > > The behaviour seems to have changed in 9.6: > > Indeed, https://www.postgresql.org/docs/current/static/release-9-6.html > has the following entry: > > * Improve the accuracy of the ln(), log(), exp(), and pow() functions > for type numeric (Dean Rasheed) Well, the test line was added with that commit (7d9a4737c268), and indeed its comment says this used to fail: +-- cases that used to error out +select 0.12 ^ (-25); + ?column? +------------------------------------------- + 104825960103961013959336.4983657883169110 +(1 row) -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 01/11/2018 11:23 AM, Alvaro Herrera wrote: > Dagfinn Ilmari Mannsåker wrote: >> ilmari@ilmari.org (Dagfinn Ilmari Mannsåker) writes: >> >>> The behaviour seems to have changed in 9.6: >> >> Indeed, https://www.postgresql.org/docs/current/static/release-9-6.html >> has the following entry: >> >> * Improve the accuracy of the ln(), log(), exp(), and pow() functions >> for type numeric (Dean Rasheed) > > Well, the test line was added with that commit (7d9a4737c268), and > indeed its comment says this used to fail: > > +-- cases that used to error out > +select 0.12 ^ (-25); > + ?column? > +------------------------------------------- > + 104825960103961013959336.4983657883169110 > +(1 row) And indeed, my starting message in this thread was that, even in my recent (e35dba475a440f73dccf9ed1fd61e3abc6ee61db) build, make check *succeeds*, and for all I can tell, that test *is* executed (it shows up in the log, and if I re-run it with digits altered, it fails). And then I can connect interactively to the same server (started fresh, not the same instance 'make check' was running, haven't tried to find a way to connect to that), issue the same select, and get the division by zero. This is somehow sensitive to some sort of state. But what sort? -Chap
On 01/11/18 11:30, Chapman Flack wrote: > And indeed, my starting message in this thread was that, even in my > recent (e35dba475a440f73dccf9ed1fd61e3abc6ee61db) build, make check > *succeeds*, and for all I can tell, that test *is* executed (it shows > up in the log, and if I re-run it with digits altered, it fails). > > And then I can connect interactively to the same server (started > fresh, not the same instance 'make check' was running, haven't tried As I began to suspect around that time, but couldn't check until now, that's what was going wrong: my wrapper script for starting the server was starting the wrong one, because it added a $PWD-relative entry to PATH, and I had cd'd when looking for the test code last night, and then hadn't noticed a different server version was being started. (I feel a little better ... I'm not insane ... just inattentive at times.) Sorry for the false alarm. -Chap