Re: Getting rid of duplicate tables.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Richard Huxton <dev(at)archonet(dot)com>
Cc: Jared Carr <jared(at)89glass(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Getting rid of duplicate tables.
Date: 2004-01-21 18:38:09
Message-ID: 8308.1074710289@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Richard Huxton <dev(at)archonet(dot)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" ...

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Alex Madon 2004-01-21 18:48:21 Re: postgresql + apache under heavy load
Previous Message Bruno Wolff III 2004-01-21 18:29:19 Re: Ending transaction inside stored function