On Tuesday 20 January 2004 19:08, Tom Lane wrote:
> Jared Carr <jared@89glass.com> writes:
> > Dec 29 16:33:44 penguin postgres[5379]: [1-1] FATAL: lock file
> > "/var/lib/pgsql/data74/postmaster.pid" already exists
> > Dec 29 16:33:44 penguin postgres[5379]: [1-2] HINT: Is another
> > postmaster (PID 1714) running in data directory "/var/lib/pgsql/data74"?
>
> > Dec 29 16:34:12 penguin postgres[5395]: [1-1] FATAL: pre-existing
> > shared memory block (key 5432001, ID 0) is still in use
> > Dec 29 16:34:12 penguin postgres[5395]: [1-2] HINT: If you're sure
> > there are no old server processes still running, remove the shared
> > memory block with the command "ipcrm",
> > Dec 29 16:34:12 penguin postgres[5395]: [1-3] or just delete the file
> > "/var/lib/pgsql/data74/postmaster.pid".
> As a Postgres maintainer, the only thing that troubles me about this
> is that the error messages from the failed postmaster start attempts
> could be read as having encouraged the operator to do exactly the
> worst possible things. I'm cc'ing this back to pgsql-general to see
> if anyone has any thoughts about rewording these messages. In
> particular it seems like the HINT for the second failure is really
> disastrous; it should tell you to kill off the old backends, not to
> zap the lockfile.
Should we not support something like "pg_ctl cleanup" which does one or more
(as necessary) of:
1. kills the backends
2. runs ipcrm
3. rm postmater.pid
Why leave it to the operator at all?
Actually, maybe it should be "pg_ctl check" and be able to support a wider
range of checks/fixes.
--
Richard Huxton
Archonet Ltd