Skip site navigation (1) Skip section navigation (2)

Re: How to shoot yourself in the foot: kill -9 postmaster

From: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: How to shoot yourself in the foot: kill -9 postmaster
Date: 2001-03-06 03:03:49
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane wrote:
> Please note that the reason we're having this discussion at
> all is that the init script may be used for purposes other than system
> shutdown.  So the argument that "it's going to happen anyway" is wrong.

Believe it or not, you just disproved your own statement that the
initscript should not take it upon itself to issue the kill -9.  So,
what if I issue '/etc/rc.d/init.d/postgresql restart' -- and backends
don't go away during the 'stop' phase, while postmaster may actually
have died?  Or is it even possible for postmaster to drop out with a
running backend out there?

No, more is needed.  But I think a careful reap through the running
backends to kill those that need killing if postmaster won't go down
might be prudent.  Currently it is not possible to run multiple
postmasters with the RPM install (I am working on that little problem,
but it won't be for 7.1's RPMset yet), so all backends that are running
on the RPM PGDATA location (which I am looking at making configurable as
well) will belong to the one postmaster.  Of course, that would be an
absolute last resort.

Oh well -- the real solution is elsewhere, anyway.  I just have to make
sure it is not data-corruption broken.  And, if leaving the -9 out
completely is the only solution, then, well, it's the only solution.
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2001-03-06 03:04:47
Subject: Re: How to shoot yourself in the foot: kill -9 postmaster
Previous:From: Bruce MomjianDate: 2001-03-06 03:00:27
Subject: mailing list messages

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group