Christoph Berg writes:
> Interestingly, the test is only failing on i386 and none of the other
> architectures, which could hint at 80-bit extended precision FP
> problems.
Yeah, that's what I'd assumed it is. We suppress that where we can
with -fexcess-precision=standard or -msse2, but I'm gues
In the meantime postgresql-14 has been accepted into Debian/experimental:
https://buildd.debian.org/status/logs.php?pkg=postgresql-14&ver=14%7Ebeta1-1
Interestingly, the test is only failing on i386 and none of the other
architectures, which could hint at 80-bit extended precision FP
problems.
(
On 5/19/21 6:32 AM, Fabien COELHO wrote:
>
>
>> Confirmed, thanks for looking. I can reproduce it on my machine with
>> -m32. It's somewhat annoying that the buildfarm didn't pick it up
>> sooner :-(
>>
>> On Wed, 19 May 2021 at 08:28, Michael Paquier
>> wrote:
>>>
>>> On Wed, May 19, 2021 at 09
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
On Wed, 19 May 2021 at 12:07, Fabien COELHO wrote:
>
> Attached patch disactivates the test with comments to outline that there
> is an issue to fix… so it is *not* removed.
>
I opted to just remove the test rather than comment it out, since the
issue highlighted isn't specific to permute(). Also
On Wed, 19 May 2021 at 11:32, Fabien COELHO 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
Hello Dean,
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 pat
Confirmed, thanks for looking. I can reproduce it on my machine with
-m32. It's somewhat annoying that the buildfarm didn't pick it up
sooner :-(
On Wed, 19 May 2021 at 08:28, Michael Paquier wrote:
On Wed, May 19, 2021 at 09:06:16AM +0200, Fabien COELHO wrote:
I see two simple approaches:
On Wed, 19 May 2021 at 00:35, Thomas Munro wrote:
>
> FWIW this is reproducible on my local Debian/gcc box with -m32,
Confirmed, thanks for looking. I can reproduce it on my machine with
-m32. It's somewhat annoying that the buildfarm didn't pick it up
sooner :-(
On Wed, 19 May 2021 at 08:28, Mi
On Wed, May 19, 2021 at 09:06:16AM +0200, Fabien COELHO wrote:
> 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 unsi
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 entirel
Thomas Munro writes:
> 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 tes
On Wed, May 19, 2021 at 11:34 AM Thomas Munro wrote:
> I don't understand any of this stuff at all, but I added a bunch of
> printfs and worked out that the first point its local variables
> diverge is here:
>
> /* Random offset */
> r = (uint64) getrand(&random_state2, 0, size - 1
On Wed, May 19, 2021 at 9:51 AM Tom Lane wrote:
> Christoph Berg writes:
> > I can reproducibly get build failures in pgbench on 32-bit i386
> > Debian, both on sid and buster. (The older Debian stretch and Ubuntu
> > bionic are unaffected. Other architectures are also fine.)
>
> The test that's
Christoph Berg writes:
> I can reproducibly get build failures in pgbench on 32-bit i386
> Debian, both on sid and buster. (The older Debian stretch and Ubuntu
> bionic are unaffected. Other architectures are also fine.)
The test that's failing came in with
6b258e3d688db14aadb58dde2a729393623106
Hi,
I can reproducibly get build failures in pgbench on 32-bit i386
Debian, both on sid and buster. (The older Debian stretch and Ubuntu
bionic are unaffected. Other architectures are also fine.)
https://pgdgbuild.dus.dg-i.net/view/Binaries/job/postgresql-14-binaries/635/
https://pgdgbuild.dus.d
16 matches
Mail list logo
