"Sahagian, David" <david.sahagian@emc.com> 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
