agora inbox for pgsql-bugs@postgresql.org
help / color / mirror / Atom feedRe: BUG #19610: Database won't start if an unrelated process is exist
2+ messages / 2 participants
[nested] [flat]
* Re: BUG #19610: Database won't start if an unrelated process is exist
@ 2026-08-12 11:26 Álvaro Herrera <alvherre@kurilemu.de>
2026-08-12 12:51 ` Re: BUG #19610: Database won't start if an unrelated process is exist Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 2+ messages in thread
From: Álvaro Herrera @ 2026-08-12 11:26 UTC (permalink / raw)
To: Daniel Gustafsson <daniel@yesql.se>; +Cc: scherbakov_lo_radarmms@mail.ru; pgsql-bugs@lists.postgresql.org
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/
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: BUG #19610: Database won't start if an unrelated process is exist
2026-08-12 11:26 Re: BUG #19610: Database won't start if an unrelated process is exist Álvaro Herrera <alvherre@kurilemu.de>
@ 2026-08-12 12:51 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 2+ messages in thread
From: Tom Lane @ 2026-08-12 12:51 UTC (permalink / raw)
To: Álvaro Herrera <alvherre@kurilemu.de>; +Cc: Daniel Gustafsson <daniel@yesql.se>; scherbakov_lo_radarmms@mail.ru; pgsql-bugs@lists.postgresql.org
=?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
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2026-08-12 12:51 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-08-12 11:26 Re: BUG #19610: Database won't start if an unrelated process is exist Álvaro Herrera <alvherre@kurilemu.de>
2026-08-12 12:51 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox