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

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

From: Alfred Perlstein <bright(at)wintelcom(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>, Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: How to shoot yourself in the foot: kill -9 postmaster
Date: 2001-03-06 05:43:13
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
* Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> [010305 19:13] wrote:
> Lamar Owen <lamar(dot)owen(at)wgcr(dot)org> writes:
> > Tom Lane wrote:
> >> Postmaster down, backends alive is not a scenario we're currently
> >> prepared for.  We need a way to plug that gap.
> > Postmaster can easily enough find out if zombie backends are 'out there'
> > during startup, right?
> If you think it's easy enough, enlighten the rest of us ;-).  Be sure
> your solution only finds leftover backends from the previous instance of
> the same postmaster, else it will prevent running multiple postmasters
> on one system.

I'm sure some sort of encoding of the PGDATA directory along with
the pids stored in the shm segment...

> > What can postmaster _do_ about it, though?  It
> > won't necessarily be able to kill them -- but it also can't control
> > them.  If it _can_ kill them, should it try?
> I think refusal to start is sufficient.  They should go away by
> themselves as their clients disconnect, and forcing the issue doesn't
> seem like it will improve matters.  The admin can kill them (hopefully
> with just a SIGTERM ;-)) if he wants to move things along ... but I'd
> not like to see a newly-starting postmaster do that automatically.

I agree, shooting down processes incorrectly should be left up to
vendors braindead scripts. :)

> > Should the backend look for the presence of its parent postmaster
> > periodically and gracefully come down if postmaster goes away without
> > the proper handshake?
> Unless we checked just before every disk write, this wouldn't represent
> a safe failure mode.  The onus has to be on the newly-starting
> postmaster, I think, not on the old backends.
> > Should a set of backends detect a new postmaster coming up and try to
> > 'sync up' with that postmaster,
> Nice try ;-).  How will you persuade the kernel that these processes are
> now children of the new postmaster?

Oh, easy, use ptrace. :)

-Alfred Perlstein - [bright(at)wintelcom(dot)net|alfred(at)freebsd(dot)org]

In response to


pgsql-hackers by date

Next:From: Zeugswetter Andreas SBDate: 2001-03-06 08:25:08
Subject: AW: WAL-based allocation of XIDs is insecure
Previous:From: Tom LaneDate: 2001-03-06 04:39:17
Subject: Proposed WAL changes

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