Re: Windows regress fails (latest HEAD)

[Alexander Lakhin]

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

Re: Windows regress fails (latest HEAD)

[Michael Paquier]

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


signature.asc
Description: PGP signature

Re: Windows regress fails (latest HEAD)

[Russell Foster]

On Tue, Nov 10, 2020 at 1:52 PM Tomas Vondra
 wrote:
>
>
>
>
> On 11/10/20 7:15 PM, Tom Lane wrote:
> > Tomas Vondra  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 

Re: Windows regress fails (latest HEAD)

[Ranier Vilela]

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

> On Tue, Nov 10, 2020 at 12:03 PM Ranier Vilela 
> wrote:
> >
> > Em sex., 26 de jun. de 2020 às 08:21, Ranier Vilela 
> escreveu:
> >>
> >> Em qui., 11 de jun. de 2020 às 10:28, Ranier Vilela <
> ranier...@gmail.com> escreveu:
> >>>
> >>> Em qui., 11 de jun. de 2020 às 10:01, Andrew Dunstan <
> andrew.duns...@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

Re: Windows regress fails (latest HEAD)

[Russell Foster]

On Tue, Nov 10, 2020 at 1:15 PM Tom Lane  wrote:
>
> Tomas Vondra  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.

Re: Windows regress fails (latest HEAD)

[Tomas Vondra]

On 11/10/20 7:15 PM, Tom Lane wrote:
> Tomas Vondra  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

Re: Windows regress fails (latest HEAD)

[Tom Lane]

Tomas Vondra  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

Re: Windows regress fails (latest HEAD)

[Tomas Vondra]

On 11/10/20 6:16 PM, Russell Foster wrote:
> On Tue, Nov 10, 2020 at 12:03 PM Ranier Vilela  wrote:
>>
>> Em sex., 26 de jun. de 2020 às 08:21, Ranier Vilela  
>> escreveu:
>>>
>>> Em qui., 11 de jun. de 2020 às 10:28, Ranier Vilela  
>>> escreveu:

 Em qui., 11 de jun. de 2020 às 10:01, Andrew Dunstan 
  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

Re: Windows regress fails (latest HEAD)

[Russell Foster]

On Tue, Nov 10, 2020 at 12:03 PM Ranier Vilela  wrote:
>
> Em sex., 26 de jun. de 2020 às 08:21, Ranier Vilela  
> escreveu:
>>
>> Em qui., 11 de jun. de 2020 às 10:28, Ranier Vilela  
>> escreveu:
>>>
>>> Em qui., 11 de jun. de 2020 às 10:01, Andrew Dunstan 
>>>  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


regression.diffs
Description: Binary data

Re: Windows regress fails (latest HEAD)

[Ranier Vilela]

Em sex., 26 de jun. de 2020 às 08:21, Ranier Vilela 
escreveu:

> Em qui., 11 de jun. de 2020 às 10:28, Ranier Vilela 
> escreveu:
>
>> Em qui., 11 de jun. de 2020 às 10:01, Andrew Dunstan <
>> andrew.duns...@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

Re: Windows regress fails (latest HEAD)

[Ranier Vilela]

Em qui., 11 de jun. de 2020 às 10:28, Ranier Vilela 
escreveu:

> Em qui., 11 de jun. de 2020 às 10:01, Andrew Dunstan <
> andrew.duns...@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

Re: Windows regress fails (latest HEAD)

[Andrew Gierth]

> "Ranier" == Ranier Vilela  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.1110611109e+100
 Ranier> +   | 1.2345678901234e+200 | 1.1110611108e+100
 Ranier> | 1.2345678901234e-200 | 1.1110611109e-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.11106111085536...e+100

for which the closest representable float8 is

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

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

1.1110611109e+100

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

-- 
Andrew (irc:RhodiumToad)

Re: Windows regress fails (latest HEAD)

[Ranier Vilela]

Em qui., 11 de jun. de 2020 às 11:00, Andrew Dunstan <
andrew.duns...@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
> >  > > 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
> > 
> >
> > It seems that I am missing something, there is no config.pl
> > , 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

Re: Windows regress fails (latest HEAD)

[Andrew Dunstan]

On 6/11/20 9:40 AM, Ranier Vilela wrote:
> Em qui., 11 de jun. de 2020 às 10:36, Andrew Dunstan
>  > 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
> 
>
> It seems that I am missing something, there is no 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 Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Windows regress fails (latest HEAD)

[Ranier Vilela]

Em qui., 11 de jun. de 2020 às 10:36, Andrew Dunstan <
andrew.duns...@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
> >  > > 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

Re: Windows regress fails (latest HEAD)

[Andrew Dunstan]

On 6/11/20 9:28 AM, Ranier Vilela wrote:
> Em qui., 11 de jun. de 2020 às 10:01, Andrew Dunstan
>  > 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 Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Windows regress fails (latest HEAD)

[Ranier Vilela]

Em qui., 11 de jun. de 2020 às 10:01, Andrew Dunstan <
andrew.duns...@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

Re: Windows regress fails (latest HEAD)

[Andrew Dunstan]

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 Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Windows regress fails (latest HEAD)

[Ranier Vilela]

Hi,
Latest HEAD, fails with windows regress tests.

 float8   ... FAILED  517 ms
 partition_prune  ... FAILED 3085 ms

regards,
Ranier VIlela


regression.diffs
Description: Binary data


regression.out
Description: Binary data