BUG #19610: Database won't start if an unrelated process is exist

On 6 Aug 2026, at 14:50, PG Bug reporting form <noreply@postgresql.org> wrote:

The following bug has been logged on the website:

Bug reference: 19610
Logged by: Lev Sch
Email address: scherbakov_lo_radarmms@mail.ru
PostgreSQL version: 18.4
Operating system: Ubuntu 18.04.4 LTS
Description:

pg_ctl: another server might be running; trying to start server anyway
waiting for server to start....2026-08-06 15:39:08.371 MSK [2102] FATAL:
lock file "postmaster.pid" already exists
2026-08-06 15:39:08.371 MSK [2102] HINT: Is another postmaster (PID 1957)
running in data directory "/media/firefly/microsdCard/database"?
stopped waiting
pg_ctl: could not start server
Examine the log output.

Steps:
1. start Postgress database
2. hard reboot system by
sudo sh -c "echo b > /proc/sysrq-trigger"
3. wait for system boot up.
4. get a PID-number from the the first line of postmaster.pid
5. create ANY process that have PID that same as PID-number
6. start Postgress database
7. The database will not start

If skip step 5 then database starts successfully.

This is not a bug, it is the intended behaviour, a process with the PID from
the .pid file which is owned by the same userid is reported this way.

--
Daniel Gustafsson

On 2026-Aug-07, Daniel Gustafsson wrote:

Steps:
1. start Postgress database
2. hard reboot system by
sudo sh -c "echo b > /proc/sysrq-trigger"
3. wait for system boot up.
4. get a PID-number from the the first line of postmaster.pid
5. create ANY process that have PID that same as PID-number
6. start Postgress database
7. The database will not start

If skip step 5 then database starts successfully.

This is not a bug, it is the intended behaviour, a process with the PID from
the .pid file which is owned by the same userid is reported this way.

Well, I'm not sure this is really intended. I'd say it's rather
emergent behavior from what we can do, which is to inquiry whether a
process with that PID exist or not; and if it does, we assume it's the
postmaster and give up. But maybe there are ways to verify whether it's
really a postmaster that indeed corresponds to that .pid file; so that
if we can determine it's not, then the .pid file is stale and we can
remove it and move on.

I guess the problem is figuring out what sort of (extremely reliable)
test we can make to verify whether a process is a postmaster or not.
If we get it wrong, the user ends up with corrupt data which definitely
is not nice.

--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/

=?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de> writes:

Well, I'm not sure this is really intended. I'd say it's rather
emergent behavior from what we can do, which is to inquiry whether a
process with that PID exist or not; and if it does, we assume it's the
postmaster and give up. But maybe there are ways to verify whether it's
really a postmaster that indeed corresponds to that .pid file; so that
if we can determine it's not, then the .pid file is stale and we can
remove it and move on.

We already check that the PID belongs to our own UID, and is not our
parent or grandparent. I doubt there is more that we can do portably.
We've already expended a bunch of sweat in this direction,
eg commit 8f5500e6b.

To my mind, this false-positive is only likely to happen if you have
a bunch of unrelated stuff getting run under the same UID, which is
already a security problem of the first magnitude. Don't do that:
create a dedicated UID for each Postgres instance you plan to run.

If we get it wrong, the user ends up with corrupt data which definitely
is not nice.

Yeah. Erring in the direction of thinking it's safe when it isn't
is far worse than erring in this direction.

regards, tom lane