Обсуждение: BUG #19391: pg_ctl: the PID file "/xxxx/postmaster.pid" is empty

The following bug has been logged on the website:

Bug reference:      19391
Logged by:          Dmitry Kovalenko
Email address:      d.kovalenko@postgrespro.ru
PostgreSQL version: 17.7
Operating system:   Linux
Description:

Hello,

My test framework uses "pg_ctl status ..." to detect a state of Postgres
instance - uninitialized, stopped, running.

Time from time, it returns the error - pg_ctl: the PID file
"/xxxx/postmaster.pid" is empty

https://github.com/postgrespro/testgres/issues/329

I think, postgres and pg_ctl do not should create a such issues.

Thanks&Regards,
Dmitry Kovalenko

On Fri, Jan 30, 2026, at 12:59 PM, PG Bug reporting form wrote:
>
> My test framework uses "pg_ctl status ..." to detect a state of Postgres
> instance - uninitialized, stopped, running.
>
> Time from time, it returns the error - pg_ctl: the PID file
> "/xxxx/postmaster.pid" is empty
>

You didn't provide enough information. Linux distro and version?

> https://github.com/postgrespro/testgres/issues/329
>

I would say that the operating system is the one that is probably removing the 
postmaster.pid. You are using /tmp as your base directory. Service like
systemd-tmpfiles-clean removes temporary files from /tmp. If systemd is not in
use, I would check the cron.


-- 
Euler Taveira
EDB   https://www.enterprisedb.com/

PG Bug reporting form <noreply@postgresql.org> writes:
> My test framework uses "pg_ctl status ..." to detect a state of Postgres
> instance - uninitialized, stopped, running.
> Time from time, it returns the error - pg_ctl: the PID file
> "/xxxx/postmaster.pid" is empty

If you're issuing "pg_ctl status" while a postmaster is starting, it's
possible that you're hitting the tiny window where CreateLockFile()
has opened the file but not yet written anything into it.

We could imagine making pg_ctl not treat this as an error, but
I'm hesitant to do so because of possibly creating race conditions
for the pg_ctl start/stop cases.  (Well, it's inherently a race
situation if you issue two concurrent starts ... what I mean is
that failing is the safest option in that scenario.)  Depending
on what you intend to do with the pg_ctl status result, acting
as if this isn't an error case could be risky there too.
Given an empty file, we can't distinguish "a postmaster is in
progress of starting" from "a postmaster died while starting",
since no PID is available to test.

            regards, tom lane

Hello,

Hope, I was able to fix this problem on a level of my code.

When I get an error "the PID file "/xxxx/postmaster.pid" is empty" I try 
to find postmaster process.

If it exists, I sleep few seconds and try to call pg_ctl again.

I am using ps + grep to find this process.

I think, it will be really useful to get this PID from "pg_ctl start" 
output instead this combination. If it possible, of course.

Thanks&Regards,

Dmitry Kovalenko

31.01.2026 4:52, Tom Lane пишет:
> PG Bug reporting form <noreply@postgresql.org> writes:
>> My test framework uses "pg_ctl status ..." to detect a state of Postgres
>> instance - uninitialized, stopped, running.
>> Time from time, it returns the error - pg_ctl: the PID file
>> "/xxxx/postmaster.pid" is empty
> If you're issuing "pg_ctl status" while a postmaster is starting, it's
> possible that you're hitting the tiny window where CreateLockFile()
> has opened the file but not yet written anything into it.
>
> We could imagine making pg_ctl not treat this as an error, but
> I'm hesitant to do so because of possibly creating race conditions
> for the pg_ctl start/stop cases.  (Well, it's inherently a race
> situation if you issue two concurrent starts ... what I mean is
> that failing is the safest option in that scenario.)  Depending
> on what you intend to do with the pg_ctl status result, acting
> as if this isn't an error case could be risky there too.
> Given an empty file, we can't distinguish "a postmaster is in
> progress of starting" from "a postmaster died while starting",
> since no PID is available to test.
>
>             regards, tom lane