Re: postmaster.pid file auto-clean up?

Michael Clark <codingninja(at)gmail(dot)com> writes:
> It does in fact appear that we are getting false-positives.
> When trying to start PG using pg_ctl, I am getting this response:
> pg_ctl: another server might be running; trying to start server anyway
> 2012-08-26 04:46:02.211 GMT [] - FATAL: lock file "postmaster.pid" already
> exists
> 2012-08-26 04:46:02.211 GMT [] - HINT: Is another postmaster (PID 8574)
> running in data directory "/Users/mclark/Library/Application
> Support/com.marketcircle.Daylite4/StorageDebug.dlpdb/Data/9_1"?

> PID 8574 is actually iTunes, not PG,

iTunes? What is that doing running under PG's userid?

If you mean that you're launching PG under some random user's UID, you
might want to think about giving it a dedicated UID instead, so as to
improve the selectivity of the same-UID check. This would also give
a good deal more protection to the database files.

> and PG was cleanly brought down on
> it's last run, there are no children processes running.

As John pointed out, if PG was in fact stopped cleanly, the pid file
would not be there.

The symptoms you've described so far seem consistent with the idea that
PG was not stopped "cleanly", but rather by kill -9 on the postmaster
(with the child processes exiting either on their own, or as soon as
they noticed they were orphans). This is not recommended practice.

> Seb figured out how to contrive this situation.
> Run PG, copy the pid file, stop pg, copy the copied pid file back to the
> data dir and edit it, replacing the old PID with that of another running
> process.

You're kidding, right? If you intentionally set out to break the
postmaster interlock, you will doubtless be able to do that, and would
still be able to break any other algorithm we might devise. Let's
confine this discussion to scenarios that could arise without
intentional interference.

regards, tom lane