Re: pgbench test failing on 14beta1 on Debian/i386 - Mailing list pgsql-hackers

From Dean Rasheed
Subject Re: pgbench test failing on 14beta1 on Debian/i386
Date
Msg-id CAEZATCWcT9Qq5B4CTcNCG2kZ+j-JMGv8y5uRY1+UGdjVSV-NxQ@mail.gmail.com
Whole thread Raw
In response to Re: pgbench test failing on 14beta1 on Debian/i386  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: pgbench test failing on 14beta1 on Debian/i386  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
On Wed, 19 May 2021 at 11:32, Fabien COELHO <coelho@cri.ensmp.fr> wrote:
>
> >> 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.

> 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).

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

Regards,
Dean



pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: Refactor "mutually exclusive options" error reporting code in parse_subscription_options
Next
From: Bharath Rupireddy
Date:
Subject: Incorrect usage of strtol, atoi for non-numeric junk inputs