Re: BUG #19391: pg_ctl: the PID file "/xxxx/postmaster.pid" is empty

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: d(dot)kovalenko(at)postgrespro(dot)ru
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #19391: pg_ctl: the PID file "/xxxx/postmaster.pid" is empty
Date: 2026-01-31 01:52:48
Message-ID: 2092582.1769824368@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

PG Bug reporting form <noreply(at)postgresql(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Álvaro Herrera 2026-01-31 16:08:10 Re: basic_archive lost archive_directory
Previous Message Dmitry Kovalenko 2026-01-31 01:27:21 Re: BUG #19391: pg_ctl: the PID file "/xxxx/postmaster.pid" is empty