Re: Windows build broken starting at da9b580d89903fee871cf54845ffa2b26bda2e11

> On May 15, 2018, at 9:29 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>
> Greetings,
>
> * Mark Dilger (hornschnorter(at)gmail(dot)com) wrote:
>>> On May 15, 2018, at 8:58 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Mark Dilger <hornschnorter(at)gmail(dot)com> writes:
>>>> My best guess at the moment is:
>>>
>>>> diff --git a/src/backend/utils/init/globals.c b/src/backend/utils/init/globals.c
>>>> index c1f0441b08..0a3163398f 100644
>>>> --- a/src/backend/utils/init/globals.c
>>>> +++ b/src/backend/utils/init/globals.c
>>>> @@ -16,8 +16,11 @@
>>>> *
>>>> *-------------------------------------------------------------------------
>>>> */
>>>> +#include <sys/stat.h>
>>>> +
>>>> #include "postgres.h"
>>>
>>>> +#include "common/file_perm.h"
>>>
>>> Yipes. Frost, you didn't really do that did you? That's a blatant
>>> break of the "c.h must come first" rule. Whether or not it broke the
>>> Windows build, there are other platforms it'll break.
>
> Evidently I managed to.
>
>>>> Indeed, the following change (shown here for illustrative purposes only; please
>>>> don't commit it this way) fixes the problem, at least in my build environment:
>>>
>>> That's pretty ugly, but what happens if you just move the <sys/stat.h>
>>> inclusion to immediately after postgres.h, as is our normal custom?
>>
>> That also works.
>
> Good, will fix.

I'm curious why the Windows build farm members did not pick this up. Or
perhaps they did? (I don't get emails about that.) If none of the animals
are configured to detect this bug, perhaps the community needs another
Windows animal configured along the lines of the build machine I am using?

Please advise...

mark