Re: BUG #16259: Cannot Use "pg_ctl start -l logfile" on Clean Installon Windows Server 2012/2016

On Fri, Feb 14, 2020 at 1:04 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:
>
> +Heath
>
> On 2/14/20 12:45 PM, Tom Lane wrote:
> > PG Bug reporting form <noreply@postgresql.org> writes:
> >> When testing PostgreSQL 12.2 on Windows built using MSVC (this potentially
> >> affects mingw too, though untested) on both Windows Server 2012 & 2016, we
> >> are having issues with a newly generated log file on a fresh PostgreSQL
> >> cluster when PostgreSQL is started with pg_ctl. If the log file was created
> >> with a prior version of PostgreSQL, or if you manually create the log file
> >> and grant the executing user the appropriate file access permissions,
> >> everything works fine.
> >> In other words, the issue occurs when passing a file name to the `-l` flag
> >> where the log file does not already exist.
> >
> > So ... why aren't we seeing that in the buildfarm?  The TAP tests
> > certainly do that, and I think the core regression tests do too.
>
> Heath can speak to this one. He's currently looking at Dory to see why
> that is.
>
> Per my quick look, there's only one animal that has Windows Server 2016
> (Dory) and none with 2012.
>
> >> We think this was introduced in 0da33c76. One approach for a fix would be to
> >> add a condition so the added code only executes if the file already exists,
> >> and if the file does not exist it executes the "snprintf" command like
> >> before.
> >
> > Without an explanation for why it's not failing everywhere, I don't
> > have a lot of faith in that being an improvement.
>
> Sure, mostly was to find a starting point.
>
> Jonathan
>

All,
   So we had a lot of issues when setting up Dory to work with the
build farm and we had to
open up some permissions to fix these issues.  We added the "CREATOR
OWNER" to have
permissions on any files created under the build farm directory.  This
is to fix broken inheritance on
Windows Server machines when using a directory created at the root
(C:\, D:\, etc).  With this change, when the
logfile gets created by pg_ctl it will default to have the permissions
necessary to write to it.
   On a clean install of Server 2016 or Server 2012 this is not the
case and without modifying the default
permissions on an install done anywhere other than in the user's home
directory.  In the PG 12.1 release
we do not see this issue and the logfile is created with the necessary
permissions for the creator to write
to this file.
   We have now reproduced this issue using 3 different versions of
Server 2016 and a version of Server 2012.
If we change the location of the logfile to be anywhere inside of the
current user's home directory, then
we do not see the issue described.  However, if you try to put the
logfile into any directory outside of the
current user's home directory this issue will manifest.

Thanks,
   Heath