Re: Question: test "aggregates" failed in 32-bit machine

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "kuroda(dot)hayato(at)fujitsu(dot)com" <kuroda(dot)hayato(at)fujitsu(dot)com>
Cc: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Question: test "aggregates" failed in 32-bit machine
Date: 2022-09-30 16:13:11
Message-ID: 650665.1664554391@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"kuroda(dot)hayato(at)fujitsu(dot)com" <kuroda(dot)hayato(at)fujitsu(dot)com> writes:
> Hmm, I was not sure about additional conditions, sorry.
> I could reproduce with followings steps:

I tried this on a 32-bit VM with gcc 11.3, but couldn't reproduce.
You said earlier

>> OS: RHEL 6.10 server
>> Arch: i686
>> Gcc: 4.4.7

That is an awfully old compiler; I fear I no longer have anything
comparable on a working platform.

The most likely theory, I think, is that that compiler is generating
slightly different floating-point code causing different plans to
be costed slightly differently than what the test case is expecting.
Probably, the different orderings of the keys in this test case have
exactly the same cost, or almost exactly, so that different roundoff
error could be enough to change the selected plan.

This probably doesn't have a lot of real-world impact, but it's
still annoying on a couple of grounds. Failing regression isn't
nice, and also this suggests that db0d67db2 is causing us to waste
time considering multiple plans with effectively equal costs.
Maybe that code needs to filter a little harder.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2022-09-30 16:35:50 Re: Question: test "aggregates" failed in 32-bit machine
Previous Message Andres Freund 2022-09-30 15:59:53 Re: [PATCH v1] [meson] add a default option prefix=/usr/local/pgsql