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 18:44:47
Message-ID: 20010306104446.O8663@fw.wintelcom.net (view raw or flat)
Thread:
Lists: pgsql-hackers
* Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> [010306 10:35] wrote:
> Alfred Perlstein <bright(at)wintelcom(dot)net> writes:
> 
> > What about encoding the shm id in the pidfile?  Then one can just ask
> > how many processes are attached to that segment?  (if it doesn't
> > exist, one can assume all backends have exited)
> 
> Hmm ... that might actually be a pretty good idea.  A small problem is
> that the shm key isn't yet selected at the time we initially create the
> lockfile, but I can't think of any reason that we could not go back and
> append the key to the lockfile afterwards.
> 
> > you want the field 'shm_nattch'
> 
> Are there any portability problems with relying on shm_nattch to be
> available?  If not, I like this a lot...

Well it's available on FreeBSD and Solaris, I'm sure Redhat has
some deamon that resets the value to 0 periodically just for kicks
so it might not be viable... :)

Seriously, there's some dispute on the type that 'shm_nattch' is,
under Solaris it's "shmatt_t" (unsigned long afaik), under FreeBSD
it's 'short' (i should fix this. :)).

But since you're really only testing for 0'ness then it shouldn't
really be a problem.

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

In response to

Responses

pgsql-hackers by date

Next:From: Andrew McMillanDate: 2001-03-06 18:47:45
Subject: Re: mailing list messages
Previous:From: Tom LaneDate: 2001-03-06 18:35:24
Subject: Re: How to shoot yourself in the foot: kill -9 postmaster

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