| From: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz>, Russell Foster <russell(dot)foster(dot)coding(at)gmail(dot)com> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Windows regress fails (latest HEAD) |
| Date: | 2021-02-06 05:00:01 |
| Message-ID: | a1638fff-9e06-af60-7cc2-04b69ce59c99@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hello hackers,
11.11.2020 04:04, Michael Paquier wrote:
> And this configuration matches exactly what you have with the host
> where the test passed.
>
> Now I do see a difference in the Windows 10 build involved, 10.0.19041
> fails but 10.0.18363 passes. I find rather hard to buy that this is
> directly a Postgres bug. The compiler version is the same, so the
> issue seems to be related to the way the code compiled is
> interpreted.
> --
> Michael
I've managed to reproduce that fail on Windows 10 Build 19042.631 (20H2).
The "actual rows" value printed there is calculated as:
double rows = planstate->instrument->ntuples / nloops;
and with a simple debugging code, I've found that
planstate->instrument->ntuples in that case is 3, and nloops is 5. So
rows = 0.6.
Surprisingly, printf("%.0f", 0.6); in this Windows build prints 0.
Best regards,
Alexander
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2021-02-06 05:07:51 | Re: Single transaction in the tablesync worker? |
| Previous Message | James Hilliard | 2021-02-06 03:53:09 | Re: [PATCH 1/1] Fix detection of pwritev support for OSX. |