From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | jkatz(at)postgresql(dot)org |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #16259: Cannot Use "pg_ctl start -l logfile" on Clean Install on Windows Server 2012/2016 |
Date: | 2020-02-14 17:45:27 |
Message-ID: | 22619.1581702327@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
PG Bug reporting form <noreply(at)postgresql(dot)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.
> 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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jonathan S. Katz | 2020-02-14 18:04:06 | Re: BUG #16259: Cannot Use "pg_ctl start -l logfile" on Clean Install on Windows Server 2012/2016 |
Previous Message | PG Bug reporting form | 2020-02-14 17:35:00 | BUG #16259: Cannot Use "pg_ctl start -l logfile" on Clean Install on Windows Server 2012/2016 |