Michael Clark <codingninja@xxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
