| From: | Álvaro Herrera <alvherre(at)kurilemu(dot)de> |
|---|---|
| To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
| Cc: | scherbakov_lo_radarmms(at)mail(dot)ru, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #19610: Database won't start if an unrelated process is exist |
| Date: | 2026-08-12 11:26:14 |
| Message-ID: | ansmw5aeWQikOu2k@alvherre.pgsql |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
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/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2026-08-12 12:51:41 | Re: BUG #19610: Database won't start if an unrelated process is exist |
| Previous Message | Holger Jakobs | 2026-08-12 10:50:57 | pg_upgrade from 17.10 to 18.4 on Ubuntu fails: Finding the real data directory for the target cluster sh: 1: (null)/postgres: not found |