All,
I have been investigating an odd Windows regression failure that I encountered.
When building from source on a Windows 10 VM using MinGW (8.1.0), I
get a random number of regression failures off the REL_13_STABLE
branch. I debugged this a little bit and found out that the "random"
number of failures is fully dependent on the machine and if I disable
the "stats_ext.sql" regression test; all other tests pass without
issue. When the "stats_ext.sql" regression test runs, it causes a
database exception and PostgreSQL crashes. This is why the number of
regression failures is random: it depends upon the speed of the
machine that is running them. However, this behavior is not seen when
building off of master.
I did some digging and determined that on the REL_13_STABLE branch
this instability was introduced with this commit
"b380484a850b6bf7d9fc0d85c555a2366e38451f"[1]. This corresponds to
commit "19f5a37b9fc48a12c77edafb732543875da2f4a3"[1] on master. I
worked backwards from there to determine when the regressions stopped
failing and determined that with commit
"be0a6666656ec3f68eb7d8e7abab5139fcd47012"[2] the regression tests are
no longer failing.
I then checked out REL_13_STABLE and cherry picked the
"be0a6666656ec3f68eb7d8e7abab5139fcd47012" commit and ran a clean full
build of postgres. This build ran through with no issues and passed
all 200 tests.
I have also built using REL_12_STABLE and earlier with no regression failures.
This failure also does not seem to occur on a Server 2016 based system
as the buildfarm machines that run these builds do not see this
regression failure. I have not fully investigated why it appears to
be confined to Windows 10 or what the issue is that causes the PG
database to die during regression.
I was hoping that I could get commit
"be0a6666656ec3f68eb7d8e7abab5139fcd47012" backpatched to the
REL_13_STABLE branch so these regression failures would be resolved.
Thanks,
Heath