Re: Windows build broken starting at da9b580d89903fee871cf54845ffa2b26bda2e11

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Mark Dilger <hornschnorter@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>, Stephen Frost <sfrost@snowman.net>, Hao Lee <mixtrue@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>
Date: 2018-05-15T15:58:04Z
Lists: pgsql-hackers
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.

> 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?

			regards, tom lane


Commits

  1. Fix for globals.c- c.h must come first

  2. Allow group access on PGDATA

  3. Refactor dir/file permissions