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 <ranier...@gmail.com> > wrote: > > > > Em sex., 26 de jun. de 2020 às 08:21, Ranier Vilela <ranier...@gmail.com> > 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
