Re: Windows build broken starting at da9b580d89903fee871cf54845ffa2b26bda2e11
Stephen Frost <sfrost@snowman.net>
From: Stephen Frost <sfrost@snowman.net>
To: Mark Dilger <hornschnorter@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgresql.org>, Hao Lee <mixtrue@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>
Date: 2018-05-15T16:29:23Z
Lists: pgsql-hackers
Greetings, * Mark Dilger (hornschnorter@gmail.com) wrote: > > On May 15, 2018, at 8:58 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Mark Dilger <hornschnorter@gmail.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. Thanks! Stephen
Commits
-
Fix for globals.c- c.h must come first
- e2b83ff556de 11.0 landed
-
Allow group access on PGDATA
- c37b3d08ca68 11.0 cited
-
Refactor dir/file permissions
- da9b580d8990 11.0 cited