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

From: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
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 11:14:36
Message-ID: CAEZATCWcT9Qq5B4CTcNCG2kZ+j-JMGv8y5uRY1+UGdjVSV-NxQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 19 May 2021 at 11:32, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)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

In response to

Responses

Browse pgsql-hackers by date

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