Thread: pg_ctl on windows can't open postmaster.pid: Permission denied

pg_ctl on windows can't open postmaster.pid: Permission denied

From
Andres Freund
Date:
Hi,

Buildfarm animal thrips just failed with a curious error:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=thrips&dt=2017-12-13%2002%3A27%3A27

============== shutting down postmaster               ==============
pg_ctl: could not open PID file
"C:/buildfarm/buildenv/HEAD/pgsql.build/src/test/regress/./tmp_check/data/postmaster.pid":Permission denied
 

otherwise there were no failures.

I wonder if we're not opening the file with the right options to allow
us to open it while it's opened for writes in another backend? In the
backend we do so via FILE_SHARE_READ pgwin32_open which backs open and
fopen in backend code.

I've not seen this error previously, so maybe this is just a random
one-off.

Greetings,

Andres Freund


Re: pg_ctl on windows can't open postmaster.pid: Permission denied

From
Thomas Munro
Date:
On Wed, Dec 13, 2017 at 4:24 PM, Andres Freund <andres@anarazel.de> wrote:
> Hi,
>
> Buildfarm animal thrips just failed with a curious error:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=thrips&dt=2017-12-13%2002%3A27%3A27
>
> ============== shutting down postmaster               ==============
> pg_ctl: could not open PID file
"C:/buildfarm/buildenv/HEAD/pgsql.build/src/test/regress/./tmp_check/data/postmaster.pid":Permission denied
 
>
> otherwise there were no failures.
>
> I wonder if we're not opening the file with the right options to allow
> us to open it while it's opened for writes in another backend? In the
> backend we do so via FILE_SHARE_READ pgwin32_open which backs open and
> fopen in backend code.

Yeah, pg_ctl.c must be using fopen directly (from Windows' libc/crt).
A sharing violation would indeed appear as errno == EACCES by my
reading of the docs so that matches your theory.  I think this code
should use pgwin32_fopen on Windows.

-- 
Thomas Munro
http://www.enterprisedb.com


Re: pg_ctl on windows can't open postmaster.pid: Permission denied

From
Thomas Munro
Date:
On Wed, Dec 13, 2017 at 5:01 PM Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> On Wed, Dec 13, 2017 at 4:24 PM, Andres Freund <andres@anarazel.de> wrote:
> > Hi,
> >
> > Buildfarm animal thrips just failed with a curious error:
> > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=thrips&dt=2017-12-13%2002%3A27%3A27
> >
> > ============== shutting down postmaster               ==============
> > pg_ctl: could not open PID file
"C:/buildfarm/buildenv/HEAD/pgsql.build/src/test/regress/./tmp_check/data/postmaster.pid":Permission denied
 
> >
> > otherwise there were no failures.
> >
> > I wonder if we're not opening the file with the right options to allow
> > us to open it while it's opened for writes in another backend? In the
> > backend we do so via FILE_SHARE_READ pgwin32_open which backs open and
> > fopen in backend code.
>
> Yeah, pg_ctl.c must be using fopen directly (from Windows' libc/crt).
> A sharing violation would indeed appear as errno == EACCES by my
> reading of the docs so that matches your theory.  I think this code
> should use pgwin32_fopen on Windows.

dory failed like this today:

============== shutting down postmaster               ==============
pg_ctl: could not open PID file
"c:/pgbuildfarm/pgbuildroot/HEAD/pgsql.build/src/test/regress/./tmp_check/data/postmaster.pid":
Permission denied

This is probably a stupid question, but after commit 0ba06e0,
shouldn't pg_ctl.c have fopen defined as pgwin32_fopen by port.h,
because it was included by c.h, because it was included by
postgres_fe.h?

-- 
Thomas Munro
https://enterprisedb.com



Re: pg_ctl on windows can't open postmaster.pid: Permission denied

From
Michael Paquier
Date:
On Sat, Mar 30, 2019 at 12:13:23AM +1300, Thomas Munro wrote:
> This is probably a stupid question, but after commit 0ba06e0,
> shouldn't pg_ctl.c have fopen defined as pgwin32_fopen by port.h,
> because it was included by c.h, because it was included by
> postgres_fe.h?

Yeah, normally pg_ctl should be using the concurrent-safe wrapper.
--
Michael

Attachment