Re: Getting rid of duplicate tables.
От | Tom Lane |
---|---|
Тема | Re: Getting rid of duplicate tables. |
Дата | |
Msg-id | 8308.1074710289@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Getting rid of duplicate tables. (Richard Huxton <dev@archonet.com>) |
Список | pgsql-general |
Richard Huxton <dev@archonet.com> writes: > On Tuesday 20 January 2004 19:08, Tom Lane wrote: >> ... 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? Well, given that the proximate cause of Jared's whole problem was incorrect use of pg_ctl (viz, "pg_ctl stop" when "pg_ctl stop -m fast" was wanted), I'm not sure that adding an even-more-destructive stop mode to pg_ctl would have helped. Someone who doesn't know when to use -m fast isn't likely to know when to use this either. Also, I doubt that pg_ctl can do a better job of this than the existing code in the postmaster. The reason that code failed in this case was that the safety interlocks were deliberately defeated (by removing the lockfile). There isn't anything that pg_ctl could do that wouldn't be subject to similar problems. So I still think what we mostly need is to improve the messages to not encourage people to do something wrong. regards, tom lane PS: this whole saga is an excellent illustration of the reasons for the rule "don't kill -9 the postmaster" ...
В списке pgsql-general по дате отправления: