| From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Christoph Berg <myon(at)debian(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
| Subject: | Re: pgbench test failing on 14beta1 on Debian/i386 |
| Date: | 2021-05-19 07:06:16 |
| Message-ID: | alpine.DEB.2.22.394.2105190857540.536342@pseudo |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>> Forgot to post the actual values:
>> r = 2563421694876090368
>> r = 2563421694876090365
>> Smells a bit like a precision problem in the workings of pg_erand48(),
>> but as soon as I saw floating point numbers I closed my laptop and ran
>> for the door.
>
> Yup. This test has a touching, but entirely unwarranted, faith in
> pg_erand48() producing bit-for-bit the same values everywhere.
Indeed.
I argued against involving any floats computation on principle, but Dean
was confident it could work, and it did simplify the code, so it did not
look that bad an option.
I see two simple approaches:
(1) use another PRNG inside pgbench, eg Knuth's which was used in some
previous submission and is very simple and IMHO better than the rand48
stuff.
(2) extend pg_*rand48() to provide an unsigned 64 bits out of the 48 bits
state.
Any preference?
--
Fabien.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fujii Masao | 2021-05-19 07:21:58 | Re: pg_get_wal_replay_pause_state() should not return 'paused' while a promotion is ongoing. |
| Previous Message | vignesh C | 2021-05-19 06:54:25 | Re: subscriptioncheck failure |