"Sahagian, David" <david.sahagian@xxxxxxx> writes: > Using Postgres 9.1 > (1) > Simulate a "power failure" by hitting "Restart" on my VMware Workstation. > (2) > Turn on the VM (without any script removing lock or socket file). > (3) > Try to start postgres. > $ pgsql/bin/pg_ctl start -D pgdata > server starting > 2013-01-14 FATAL: lock file "/tmp/.s.PGSQL.5432.lock" already exists > 2013-01-14 HINT: Is another postmaster (PID 2770) using socket file "/tmp/.s.PGSQL.5432"? This should only happen if PID 2770 currently exists, belongs to a process running under the postgres userid (or the same UID as this postmaster, to be precise), and is not either the postmaster's parent or grandparent process (which in the quoted scenario would be pg_ctl or your shell respectively). While it's conceivable that these heuristics could be fooled, it's not very likely, and it wouldn't be reproducible either. So I think there is more going on in your scenario than you have told us about. Another possibility that maybe should be considered is that the postmaster's kill() check to see if the PID is live returns some error other than ESRCH or EPERM. That would be a portability issue that we'd need to fix, but I'm not aware of any platforms where there's another error code to worry about. > So to be able to start Postgres . . . > In our "vm startup script", should we remove only the [.s.PGSQL.5432.lock] file ? > Or should we also remove the [.s.PGSQL.5432] file ? I would urgently recommend that no startup script remove either lockfile. Ever. The prospects of shooting yourself in the foot (by allowing duplicate postmasters to start) greatly outweigh any possible benefit. 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
