Re: why not kill -9 postmaster

After all that discussion that took place while i was sleeping, I have a few
more questions simply haunting me.

Someitmes, rather most of the times, when I start postgres using pg_ctl, it
says antoher postmaster is running. Being a total naive about the hazzards
of kill -9 postmaster, i simply used to kill -9 all postmaster related
process IDs.
Now, what should i do to get rid of the postmaster that is already running
from a safe perspective.
Also, even though it says, postmaster is still running, i can't start my
pgadmin because it starts crying over the fact that postgres server is not
running.
Another thing that worries me is the importance of postmaster.pid.
What happens if I simply do rm postmaster.pid after killing all the
postmaster processes.
How big a pain in the neck is that going to be?

Thanks,
~Harpreet

On 10/20/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> > Well, if you kill -9 the postmaster all the connections stay alive and
> > stay processing tuples and writing to disk, except the coordination is
> > gone.
>
> The postmaster isn't involved in any critical inter-backend coordination.
> If you kill -9 the postmaster *and then kill or wait out all the
> backends*, you won't lose data. This is not a desirable long-term
> operating mode, because it cripples autovacuum and some other things,
> but it's not dangerous.
>
> The only really serious risk I'm aware of in this scenario is:
>
> 1. DBA does "kill -9" postmaster, but some backends are still alive and
> processing.
>
> 2. DBA tries to start new postmaster, gets message about "shared memory
> segment still in use".
>
> 3. DBA does "rm postmaster.pid" (this is the step that qualifies him
> as an idiot).
>
> 4. DBA starts new postmaster. Since the interlock file is gone, it
> starts up without any awareness that there are old backends still alive.
>
> At this point, you have two separate sets of backends that are not
> communicating (they're using two different shared memory segments)
> but they are munging the same data files. It will not take long
> to turn the data files into irrecoverable hash --- for just one
> reason, transaction numbering will diverge between the two sets of
> backends.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>