=?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
