On Wed, Mar 26, 2025 at 2:09 PM Robert Haas <robertmh...@gmail.com> wrote:
> Hearing no other votes against this, I have committed it, but now I
> wonder if that is going to break the buildfarm, because I just noticed
> that the changes I made in v9 seem not to have resolved the problem
> with debug_parallel_query, for reasons I do not yet understand.
> Investigating...
I pushed a couple of fixes for this, but I still see one failure, on drongo:
diff --strip-trailing-cr -U3
C:/prog/bf/root/HEAD/pgsql/contrib/pg_overexplain/expected/pg_overexplain.out
C:/prog/bf/root/HEAD/pgsql.build/testrun/pg_overexplain/regress/results/pg_overexplain.out
---
C:/prog/bf/root/HEAD/pgsql/contrib/pg_overexplain/expected/pg_overexplain.out
2025-03-26 20:33:47.834896600 +0000
+++
C:/prog/bf/root/HEAD/pgsql.build/testrun/pg_overexplain/regress/results/pg_overexplain.out
2025-03-26 21:57:55.332431300 +0000
@@ -419,7 +419,7 @@
Plan Node ID: 5
extParam: 0
allParam: 0
- -> Index Scan using daucus_id_idx on daucus v2_2 (actual
rows=0.12 loops=8)
+ -> Index Scan using daucus_id_idx on daucus v2_2 (actual
rows=0.13 loops=8)
Index Cond: (id = v1.id)
Index Searches: 8
Disabled Nodes: 0
As some of you will recall, I hate floating point arithmetic with a
fiery passion, but I'm still surprised to learn that 1/8 rounded to
two decimal places does not produce the same answer on all modern
systems. It's not even like this is some weird architecture -- it's
listed as x86_64. I'll look into a fix for this in the morning.
--
Robert Haas
EDB: http://www.enterprisedb.com
