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

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)

* which configuration settings you're using

None. Only build with default configuration (release is default).

* what are the regression differences you get in the failing tests

It was sent as an attachment.

regards,
Ranier Vilela

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

Em qui., 11 de jun. de 2020 às 10:36, Andrew Dunstan <
andrew.dunstan@2ndquadrant.com> escreveu:

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

Ok.

* 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

It seems that I am missing something, there is no config.pl, anywhere in
the postgres directory.

* 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.

Ah yes, ok, I'll remember that.

regards,
Ranier Vilela

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&gt;

It seems that I am missing something, there is no config.pl
<http://config.pl&gt;, 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

Em qui., 11 de jun. de 2020 às 11:00, Andrew Dunstan <
andrew.dunstan@2ndquadrant.com> escreveu:

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&gt;

It seems that I am missing something, there is no config.pl
<http://config.pl&gt;, anywhere in the postgres directory.

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

I see.
As I did a clean build, from github (git clone), there is no config.pl, so,
was using the same file.
(
https://github.com/postgres/postgres/blob/master/src/tools/msvc/config_default.pl
)

regards,
Ranier VIlela

"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)

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.

regards,
Ranier Vilela

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

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

Em ter., 10 de nov. de 2020 às 14:16, Russell Foster <
russell.foster.coding@gmail.com> escreveu:

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?

Hi Russel,
In DEBUG mode, the issue is gone (all 202 tests pass).
You can be sure yourself.
I think that compiler code generation bug...

Ranier Vilela

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&amp;dt=2020-11-10%2018%3A59%3A20&amp;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