Thread: Windows regress fails (latest HEAD)

On 6/11/20 8:52 AM, Ranier Vilela wrote:
> Hi,
> Latest HEAD, fails with windows regress tests.
>
>  float8                       ... FAILED      517 ms
>  partition_prune              ... FAILED     3085 ms
>
>

Ranier,


The first thing you should do when you find this is to see if there is a
buildfarm report of the failure. If there isn't then try to work out why.

Also, when making a report like this, it is essential to let us know
things like:

  * which commit is causing the failure (git bisect is good for finding
    this)
  * what Windows version you're testing on
  * which compiler you're using
  * which configuration settings you're using
  * what are the regression differences you get in the failing tests

Without that we can't do anything with your report because it just
doesn't have enough information


cheers


andrew



-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 6/11/20 9:28 AM, Ranier Vilela wrote:
> Em qui., 11 de jun. de 2020 às 10:01, Andrew Dunstan
> <andrew.dunstan@2ndquadrant.com
> <mailto:andrew.dunstan@2ndquadrant.com>> escreveu:
>
>
>     On 6/11/20 8:52 AM, Ranier Vilela wrote:
>     > Hi,
>     > Latest HEAD, fails with windows regress tests.
>     >
>     >  float8                       ... FAILED      517 ms
>     >  partition_prune              ... FAILED     3085 ms
>     >
>     >
>
>     The first thing you should do when you find this is to see if
>     there is a
>     buildfarm report of the failure. If there isn't then try to work
>     out why.
>
> Sorry, I will have to research the buildfarm, I have no reference to it.
>  


See https://buildfarm.postgresql.org


>
>       * which configuration settings you're using
>
> None. Only build with default configuration (release is default).


We would also need to see the contents of your config.pl


>
>       * what are the regression differences you get in the failing tests
>
> It was sent as an attachment.
>
>

If you send attachments please refer to them in the body of your email,
otherwise they are easily missed, as I did.


cheers


andrew


-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 6/11/20 9:40 AM, Ranier Vilela wrote:
> Em qui., 11 de jun. de 2020 às 10:36, Andrew Dunstan
> <andrew.dunstan@2ndquadrant.com
> <mailto:andrew.dunstan@2ndquadrant.com>> escreveu:
>
>
>
>
>
>     >
>     >       * which configuration settings you're using
>     >
>     > None. Only build with default configuration (release is default).
>
>
>     We would also need to see the contents of your config.pl
>     <http://config.pl>
>
> It seems that I am missing something, there is no config.pl
> <http://config.pl>, anywhere in the postgres directory.



If there isn't one it uses config_default.pl.


See src/tools/msvc/README which includes this snippet:


    The tools for building PostgreSQL using Microsoft Visual Studio
    currently
    consist of the following files:

    - Configuration files -
    config_default.pl      default configuration arguments

    A typical build environment has two more files, buildenv.pl and
    config.pl
    that contain the user's build environment settings and configuration
    arguments.

cheers


andrew


-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

>>>>> "Ranier" == Ranier Vilela <ranier.vf@gmail.com> writes:

 Ranier> Hi,
 Ranier> Latest HEAD, fails with windows regress tests.

 Ranier>   three |          f1          |        sqrt_f1        
 Ranier>  -------+----------------------+-----------------------
 Ranier>         |               1004.3 |      31.6906926399535
 Ranier> -       | 1.2345678901234e+200 | 1.11111110611109e+100
 Ranier> +       | 1.2345678901234e+200 | 1.11111110611108e+100
 Ranier>         | 1.2345678901234e-200 | 1.11111110611109e-100
 Ranier>  (3 rows)

This error is a surprisingly large one. Normally one expects sqrt to be
accurate to within half an ulp, i.e. accurate to the limits of the
format, though the regression test avoids actually making this
assumption. But in this case the true output we expect is:

1.111111106111085536...e+100

for which the closest representable float8 is

1.111111106111085583...e+100  (= 0x1.451DCD2E3ACAFp+332)

which should round (since we're doing this test with
extra_float_digits=0) to

1.11111110611109e+100

The nearest value that would round to 1.11111110611108e+100 would be
1.1111111061110848e+100 (= 0x1.451DCD2E3ACABp+332), which is a
difference of not less than 4 ulps from the expected value.

-- 
Andrew (irc:RhodiumToad)

On Tue, Nov 10, 2020 at 12:03 PM Ranier Vilela <ranier.vf@gmail.com> wrote:
>
> Em sex., 26 de jun. de 2020 às 08:21, Ranier Vilela <ranier.vf@gmail.com> escreveu:
>>
>> Em qui., 11 de jun. de 2020 às 10:28, Ranier Vilela <ranier.vf@gmail.com> escreveu:
>>>
>>> Em qui., 11 de jun. de 2020 às 10:01, Andrew Dunstan <andrew.dunstan@2ndquadrant.com> escreveu:
>>>>
>>>>
>>>> On 6/11/20 8:52 AM, Ranier Vilela wrote:
>>>> > Hi,
>>>> > Latest HEAD, fails with windows regress tests.
>>>> >
>>>> >  float8                       ... FAILED      517 ms
>>>> >  partition_prune              ... FAILED     3085 ms
>>>> >
>>>> >
>>>>
>>>> The first thing you should do when you find this is to see if there is a
>>>> buildfarm report of the failure. If there isn't then try to work out why.
>>>
>>> Sorry, I will have to research the buildfarm, I have no reference to it.
>>>
>>>>
>>>>
>>>> Also, when making a report like this, it is essential to let us know
>>>> things like:
>>>>
>>>>   * which commit is causing the failure (git bisect is good for finding
>>>>     this)
>>>
>>> Thanks for hit (git bisect).
>>>
>>>>
>>>>   * what Windows version you're testing on
>>>
>>> Windows 10 (2004)
>>>
>>>>   * which compiler you're using
>>>
>>> msvc 2019 (64 bits)
>>
>>
>> Only for registry, if anyone else is using msvc 2019.
>> I'm using latest msvc 2019 64 bits (16.6.0)
>> Problably this is a compiler optimization bug.
>> vcregress check with build DEBUG, pass all 200 tests.
>
> With the current HEAD, the regression float8 in release mode (msvc 2019 64 bits) is gone.
> Maybe it's this commit:
> https://github.com/postgres/postgres/commit/0aa8f764088ea0f36620ae2955fa6c54ec736c46
>
> But (partition_prune) persists.
> partition_prune              ... FAILED
>
> regards,
> Ranier Vilela

I am also experiencing this issue on one of my Windows machines (x64)
using 12.4. I believe this is new, possibly since 12.2. It doesn't
occur on another machine though, which is strange. It appears to be
the same diff output. Is it possible that the given result is also
valid for this test?

Russell

On 11/10/20 6:16 PM, Russell Foster wrote:
> On Tue, Nov 10, 2020 at 12:03 PM Ranier Vilela <ranier.vf@gmail.com> wrote:
>>
>> Em sex., 26 de jun. de 2020 às 08:21, Ranier Vilela <ranier.vf@gmail.com> escreveu:
>>>
>>> Em qui., 11 de jun. de 2020 às 10:28, Ranier Vilela <ranier.vf@gmail.com> escreveu:
>>>>
>>>> Em qui., 11 de jun. de 2020 às 10:01, Andrew Dunstan <andrew.dunstan@2ndquadrant.com> escreveu:
>>>>>
>>>>>
>>>>> On 6/11/20 8:52 AM, Ranier Vilela wrote:
>>>>>> Hi,
>>>>>> Latest HEAD, fails with windows regress tests.
>>>>>>
>>>>>>  float8                       ... FAILED      517 ms
>>>>>>  partition_prune              ... FAILED     3085 ms
>>>>>>
>>>>>>
>>>>>
>>>>> The first thing you should do when you find this is to see if there is a
>>>>> buildfarm report of the failure. If there isn't then try to work out why.
>>>>
>>>> Sorry, I will have to research the buildfarm, I have no reference to it.
>>>>
>>>>>
>>>>>
>>>>> Also, when making a report like this, it is essential to let us know
>>>>> things like:
>>>>>
>>>>>   * which commit is causing the failure (git bisect is good for finding
>>>>>     this)
>>>>
>>>> Thanks for hit (git bisect).
>>>>
>>>>>
>>>>>   * what Windows version you're testing on
>>>>
>>>> Windows 10 (2004)
>>>>
>>>>>   * which compiler you're using
>>>>
>>>> msvc 2019 (64 bits)
>>>
>>>
>>> Only for registry, if anyone else is using msvc 2019.
>>> I'm using latest msvc 2019 64 bits (16.6.0)
>>> Problably this is a compiler optimization bug.
>>> vcregress check with build DEBUG, pass all 200 tests.
>>
>> With the current HEAD, the regression float8 in release mode (msvc 2019 64 bits) is gone.
>> Maybe it's this commit:
>> https://github.com/postgres/postgres/commit/0aa8f764088ea0f36620ae2955fa6c54ec736c46
>>
>> But (partition_prune) persists.
>> partition_prune              ... FAILED
>>
>> regards,
>> Ranier Vilela
> 
> I am also experiencing this issue on one of my Windows machines (x64)
> using 12.4. I believe this is new, possibly since 12.2. It doesn't
> occur on another machine though, which is strange. It appears to be
> the same diff output. Is it possible that the given result is also
> valid for this test?
> 

That's unlikely, I think. The regression tests are constructed so that
the estimates are stable. It's more likely this is some difference in
rounding behavior, for example. I wonder which msvc builds are used on
the machines that fail/pass the tests, and if the compiler flags are the
same.

regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
> That's unlikely, I think. The regression tests are constructed so that
> the estimates are stable. It's more likely this is some difference in
> rounding behavior, for example.

The reported delta is in the actual row count, not an estimate.
How could that be subject to roundoff issues?  And there's no
delta in the Append's inputs, so this seems like it's a flat-out
miss of a row count in EXPLAIN ANALYZE.

> I wonder which msvc builds are used on
> the machines that fail/pass the tests, and if the compiler flags are the
> same.

Yeah, this might be a fruitful way to figure out "what's different
from the buildfarm".

            regards, tom lane

On Tue, Nov 10, 2020 at 1:15 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
> > That's unlikely, I think. The regression tests are constructed so that
> > the estimates are stable. It's more likely this is some difference in
> > rounding behavior, for example.
>
> The reported delta is in the actual row count, not an estimate.
> How could that be subject to roundoff issues?  And there's no
> delta in the Append's inputs, so this seems like it's a flat-out
> miss of a row count in EXPLAIN ANALYZE.
>
> > I wonder which msvc builds are used on
> > the machines that fail/pass the tests, and if the compiler flags are the
> > same.
>
> Yeah, this might be a fruitful way to figure out "what's different
> from the buildfarm".
>
>                         regards, tom lane

Hmm..anyway I can help here? I don't believe I am using any special
compile options. I am using VS 2019. The thing is, both systems I have
use the same build. I call msvcvars to set up the environment:

"%ProgramFiles(x86)%\Microsoft Visual
Studio\2019\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" amd64

I also saw some recent changes have been made around these tests, so I
can try the latest too.

On 11/10/20 7:15 PM, Tom Lane wrote:
> Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
>> That's unlikely, I think. The regression tests are constructed so that
>> the estimates are stable. It's more likely this is some difference in
>> rounding behavior, for example.
> 
> The reported delta is in the actual row count, not an estimate.
> How could that be subject to roundoff issues?  And there's no
> delta in the Append's inputs, so this seems like it's a flat-out
> miss of a row count in EXPLAIN ANALYZE.
> 

My bad. I've not noticed it's EXPLAIN ANALYZE (COSTS OFF) so I thought
it's estimates. You're right this can't be a roundoff error.

>> I wonder which msvc builds are used on the machines that fail/pass
>> the tests, and if the compiler flags are the same.
> 
> Yeah, this might be a fruitful way to figure out "what's different
> from the buildfarm".
> 

Yeah. Also Russell claims to have two "same" machines out of which one
works and the other one fails.

regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Tue, Nov 10, 2020 at 1:52 PM Tomas Vondra
<tomas.vondra@enterprisedb.com> wrote:
>
>
>
>
> On 11/10/20 7:15 PM, Tom Lane wrote:
> > Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
> >> That's unlikely, I think. The regression tests are constructed so that
> >> the estimates are stable. It's more likely this is some difference in
> >> rounding behavior, for example.
> >
> > The reported delta is in the actual row count, not an estimate.
> > How could that be subject to roundoff issues?  And there's no
> > delta in the Append's inputs, so this seems like it's a flat-out
> > miss of a row count in EXPLAIN ANALYZE.
> >
>
> My bad. I've not noticed it's EXPLAIN ANALYZE (COSTS OFF) so I thought
> it's estimates. You're right this can't be a roundoff error.
>
> >> I wonder which msvc builds are used on the machines that fail/pass
> >> the tests, and if the compiler flags are the same.
> >
> > Yeah, this might be a fruitful way to figure out "what's different
> > from the buildfarm".
> >
>
> Yeah. Also Russell claims to have two "same" machines out of which one
> works and the other one fails.

Never claimed they were the same, but they are both Windows x64. Here
are some more details:

Test Passes:
VM machine (Build Server)
Microsoft Windows 10 Pro
Version 10.0.18363 Build 18363
Microsoft (R) C/C++ Optimizing Compiler Version 19.27.29112 for x64

Compile args:
C:\Program Files (x86)\Microsoft Visual
Studio\2019\Enterprise\VC\Tools\MSVC\14.27.29110\bin\HostX86\x64\CL.exe
/c /Isrc/include /Isrc/include/port/win32
/Isrc/include/port/win32_msvc /Iexternals/zlib
/Iexternals/openssl\include /Isrc/backend /Zi /nologo /W3 /WX-
/diagnostics:column /Ox /D WIN32 /D _WINDOWS /D __WINDOWS__ /D
__WIN32__ /D EXEC_BACKEND /D WIN32_STACK_RLIMIT=4194304 /D
_CRT_SECURE_NO_DEPRECATE /D _CRT_NONSTDC_NO_DEPRECATE /D BUILDING_DLL
/D _MBCS /GF /Gm- /EHsc /MD /GS /fp:precise /Zc:wchar_t /Zc:forScope
/Zc:inline /Fo".\Release\postgres\\" /Fd".\Release\postgres\vc142.pdb"
/Gd /TC /wd4018 /wd4244 /wd4273 /wd4102 /wd4090 /wd4267 /FC
/errorReport:queue /MP src/backend/catalog/partition.c

Test Fails:
Laptop machine (Development)
Microsoft Windows 10 Enterprise
Version 10.0.19041 Build 19041
Microsoft (R) C/C++ Optimizing Compiler Version 19.27.29112 for x64

Compile args:
C:\Program Files (x86)\Microsoft Visual
Studio\2019\Enterprise\VC\Tools\MSVC\14.27.29110\bin\HostX86\x64\CL.exe
/c /Isrc/include /Isrc/include/port/win32
/Isrc/include/port/win32_msvc /Iexternals/zlib
/Iexternals/openssl\include /Isrc/backend /Zi /nologo /W3 /WX-
/diagnostics:column /Ox /D WIN32 /D _WINDOWS /D __WINDOWS__ /D
__WIN32__ /D EXEC_BACKEND /D WIN32_STACK_RLIMIT=4194304 /D
_CRT_SECURE_NO_DEPRECATE /D _CRT_NONSTDC_NO_DEPRECATE /D BUILDING_DLL
/D _MBCS /GF /Gm- /EHsc /MD /GS /fp:precise /Zc:wchar_t /Zc:forScope
/Zc:inline /Fo".\Release\postgres\\" /Fd".\Release\postgres\vc142.pdb"
/Gd /TC /wd4018 /wd4244 /wd4273 /wd4102 /wd4090 /wd4267 /FC
/errorReport:queue /MP src/backend/catalog/partition.c

>
> regards
>
> --
> Tomas Vondra
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company

Compiler versions are the same and the build args seem the same. Also,
tried with the latest REL_12_STABLE and REL_13_STABLE, and they both
fail on my dev machine as well.

I'm not going to pretend to know why the explain should be equal in
this case, but I wonder what difference it would make if the output
for both is equal and/or correct? From parttion_prune.out on the
failing machine, line 2810:

-- Multiple partitions
insert into tbl1 values (1001), (1010), (1011);
explain (analyze, costs off, summary off, timing off)
select * from tbl1 inner join tprt on tbl1.col1 > tprt.col1;
                                QUERY PLAN
--------------------------------------------------------------------------
 Nested Loop (actual rows=23 loops=1)
   ->  Seq Scan on tbl1 (actual rows=5 loops=1)
   ->  Append (actual rows=5 loops=5)
         ->  Index Scan using tprt1_idx on tprt_1 (actual rows=2 loops=5)
               Index Cond: (col1 < tbl1.col1)
         ->  Index Scan using tprt2_idx on tprt_2 (actual rows=3 loops=4)
               Index Cond: (col1 < tbl1.col1)
         ->  Index Scan using tprt3_idx on tprt_3 (actual rows=1 loops=2)
               Index Cond: (col1 < tbl1.col1)
         ->  Index Scan using tprt4_idx on tprt_4 (never executed)
               Index Cond: (col1 < tbl1.col1)
         ->  Index Scan using tprt5_idx on tprt_5 (never executed)
               Index Cond: (col1 < tbl1.col1)
         ->  Index Scan using tprt6_idx on tprt_6 (never executed)
               Index Cond: (col1 < tbl1.col1)
(15 rows)

explain (analyze, costs off, summary off, timing off)
select * from tbl1 inner join tprt on tbl1.col1 = tprt.col1;
                                QUERY PLAN
--------------------------------------------------------------------------
 Nested Loop (actual rows=3 loops=1)
   ->  Seq Scan on tbl1 (actual rows=5 loops=1)
   ->  Append (actual rows=0 loops=5)
         ->  Index Scan using tprt1_idx on tprt_1 (never executed)
               Index Cond: (col1 = tbl1.col1)
         ->  Index Scan using tprt2_idx on tprt_2 (actual rows=1 loops=2)
               Index Cond: (col1 = tbl1.col1)
         ->  Index Scan using tprt3_idx on tprt_3 (actual rows=0 loops=3)
               Index Cond: (col1 = tbl1.col1)
         ->  Index Scan using tprt4_idx on tprt_4 (never executed)
               Index Cond: (col1 = tbl1.col1)
         ->  Index Scan using tprt5_idx on tprt_5 (never executed)
               Index Cond: (col1 = tbl1.col1)
         ->  Index Scan using tprt6_idx on tprt_6 (never executed)
               Index Cond: (col1 = tbl1.col1)
(15 rows)

select tbl1.col1, tprt.col1 from tbl1
inner join tprt on tbl1.col1 > tprt.col1
order by tbl1.col1, tprt.col1;
 col1 | col1
------+------
  501 |   10
  501 |   20
  505 |   10
  505 |   20
  505 |  501
  505 |  502
 1001 |   10
 1001 |   20
 1001 |  501
 1001 |  502
 1001 |  505
 1010 |   10
 1010 |   20
 1010 |  501
 1010 |  502
 1010 |  505
 1010 | 1001
 1011 |   10
 1011 |   20
 1011 |  501
 1011 |  502
 1011 |  505
 1011 | 1001
(23 rows)

select tbl1.col1, tprt.col1 from tbl1
inner join tprt on tbl1.col1 = tprt.col1
order by tbl1.col1, tprt.col1;
 col1 | col1
------+------
  501 |  501
  505 |  505
 1001 | 1001
(3 rows)

Here the selects return the same values as the expected.

On Tue, Nov 10, 2020 at 04:22:37PM -0500, Russell Foster wrote:
> Never claimed they were the same, but they are both Windows x64. Here
> are some more details:
>
> Test Passes:
> VM machine (Build Server)
> Microsoft Windows 10 Pro
> Version 10.0.18363 Build 18363
> Microsoft (R) C/C++ Optimizing Compiler Version 19.27.29112 for x64
>
> Compile args:
> C:\Program Files (x86)\Microsoft Visual
> Studio\2019\Enterprise\VC\Tools\MSVC\14.27.29110\bin\HostX86\x64\CL.exe
> /c /Isrc/include /Isrc/include/port/win32
> /Isrc/include/port/win32_msvc /Iexternals/zlib
> /Iexternals/openssl\include /Isrc/backend /Zi /nologo /W3 /WX-
> /diagnostics:column /Ox /D WIN32 /D _WINDOWS /D __WINDOWS__ /D
> __WIN32__ /D EXEC_BACKEND /D WIN32_STACK_RLIMIT=4194304 /D
> _CRT_SECURE_NO_DEPRECATE /D _CRT_NONSTDC_NO_DEPRECATE /D BUILDING_DLL
> /D _MBCS /GF /Gm- /EHsc /MD /GS /fp:precise /Zc:wchar_t /Zc:forScope
> /Zc:inline /Fo".\Release\postgres\\" /Fd".\Release\postgres\vc142.pdb"
> /Gd /TC /wd4018 /wd4244 /wd4273 /wd4102 /wd4090 /wd4267 /FC
> /errorReport:queue /MP src/backend/catalog/partition.c

drongo is the closest thing we have in the buildfarm for this setup.
Here is the boring option part when it comes to Postgres compilation:
https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=drongo&dt=2020-11-10%2018%3A59%3A20&stg=make
  C:\\Program Files (x86)\\Microsoft Visual
  Studio\\2019\\BuildTools\\VC\\Tools\\MSVC\\14.23.28105\\bin\\HostX86\\x64\\CL.exe
  /c /Isrc/include /Isrc/include/port/win32
  /Isrc/include/port/win32_msvc /Ic:\\prog\\3p64\\include
  /I"C:\\Program Files\\OpenSSL-Win64\\include" /Isrc/backend /Zi
  /nologo /W3 /WX- /diagnostics:column /Ox /D WIN32 /D _WINDOWS /D
  __WINDOWS__ /D __WIN32__ /D WIN32_STACK_RLIMIT=4194304 /D
  _CRT_SECURE_NO_DEPRECATE /D _CRT_NONSTDC_NO_DEPRECATE /D
  BUILDING_DLL /D _MBCS /GF /Gm- /EHsc /MD /GS /fp:precise /Zc:wchar_t
  /Zc:forScope /Zc:inline /Fo".\\Release\\postgres\\\\"
  /Fd".\\Release\\postgres\\vc142.pdb" /Gd /TC /wd4018 /wd4244 /wd4273
  /wd4102 /wd4090 /wd4267 /FC /errorReport:queue /MP [ source files ]
 [...]

So except if I am missing something we have an exact match here.

> Test Fails:
> Laptop machine (Development)
> Microsoft Windows 10 Enterprise
> Version 10.0.19041 Build 19041
> Microsoft (R) C/C++ Optimizing Compiler Version 19.27.29112 for x64
>
> Compile args:
> C:\Program Files (x86)\Microsoft Visual
> Studio\2019\Enterprise\VC\Tools\MSVC\14.27.29110\bin\HostX86\x64\CL.exe
> /c /Isrc/include /Isrc/include/port/win32
> /Isrc/include/port/win32_msvc /Iexternals/zlib
> /Iexternals/openssl\include /Isrc/backend /Zi /nologo /W3 /WX-
> /diagnostics:column /Ox /D WIN32 /D _WINDOWS /D __WINDOWS__ /D
> __WIN32__ /D EXEC_BACKEND /D WIN32_STACK_RLIMIT=4194304 /D
> _CRT_SECURE_NO_DEPRECATE /D _CRT_NONSTDC_NO_DEPRECATE /D BUILDING_DLL
> /D _MBCS /GF /Gm- /EHsc /MD /GS /fp:precise /Zc:wchar_t /Zc:forScope
> /Zc:inline /Fo".\Release\postgres\\" /Fd".\Release\postgres\vc142.pdb"
> /Gd /TC /wd4018 /wd4244 /wd4273 /wd4102 /wd4090 /wd4267 /FC
> /errorReport:queue /MP src/backend/catalog/partition.c

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

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