Re: pgbench test failing on 14beta1 on Debian/i386

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Christoph Berg <myon(at)debian(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgbench test failing on 14beta1 on Debian/i386
Date: 2021-05-19 15:25:10
Message-ID: alpine.DEB.2.22.394.2105191629560.536342@pseudo
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


>>>> Or, (3) remove this test? I am not quite sure what there is to gain
>>>> with this extra test considering all the other tests with permute()
>>>> already present in this script.
>>>
>>> Yes, I think removing the test is the best option. It was originally
>>> added because there was a separate code path for larger permutation
>>> sizes that needed testing, but that's no longer the case so the test
>>> really isn't adding anything.
>>
>> Hmmm…
>>
>> It is the one test which worked in actually detecting an issue, so I would
>> not say that it is not adding anything, on the contrary, it did prove its
>> value! The permute function is expected to be deterministic on different
>> platforms and architectures, and it is not.
>>
>
> In fact what it demonstrates is that the results from permute(), like
> all the other pgbench random functions, will vary by platform for
> sufficiently large size parameters.

Indeed, it is the case if the underlying math use doubles & large numbers.
For integer-only computations it should be safe though, and permute should
be in this category.

>> I'd agree with a two phases approach: drop the test in the short term and
>> deal with the PRNG later. I'm sooooo unhappy with this 48 bit PRNG that I
>> may be motivated enough to attempt to replace it, or at least add a better
>> (faster?? larger state?? same/better quality?) alternative.
>
> I don't necessarily have a problem with that provided the replacement
> is well-chosen and has a proven track record (i.e., let's not invent
> our own PRNG).

Yes, obviously, I'm not daft enough to reinvent a PRNG. The question is to
chose one, motivate the choice, and build the relevant API for what pg
needs, possibly with some benchmarking.

> For now though, I'll go remove the test.

This also removes the reminder…

--
Fabien.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2021-05-19 15:48:47 Re: libpq_pipeline in tmp_install
Previous Message Tom Lane 2021-05-19 15:06:51 Re: libpq_pipeline in tmp_install