You will find that that script is not distributed by us.
[ Charset ISO-8859-1 unsupported, converting... ]
> I believe i found two minor bugs in the linux start/stop scripts for the
> downloadable rpm version of postgres 7.1. I don't think these have been
> reported already (i did some quik searches). Please look these over and see
> if i'm just smoking something or if these bugs are valid. Also, i did a
> quick cvs checkout / log of the contrib tree, and i noted that the
> start/stop scripts have been restructured recently (i do not know where
> logic of the scripts were moved to, so these points may still be valid, if
> not, i was wondering if I pull the scripts from the cvs contrib tree myself,
> would they work out of the box?).
> #1. Every instance of (there are 2):
> pid=`pidof postmaster`
> if [ $pid ]
> should be:
> pid=`pidof -s postmaster`
> if [ $pid ]
> (pidof may return multiple pids if postmaster forked or has multiple threads
> -- i'm not toofamiliar with postgres architecture, but postmaster does
> sometimes show multiple pids which could mean multiple threads or processes
> in linux) If pidof returns multiple pids, the "if" will barf giving
> something like the following:
> Stopping postgresql service: [ OK ]
> Checking postgresql installation: [ OK ]
> /etc/rc.d/init.d/postgresql: [: 1223: unary operator expected
> Starting postgresql service: [FAILED]
> #2. /etc/rc.d/init.d/postgresql restart sometimes doesn't do what it should.
> ie. end up with a fresh newly started postgres daemon.
> This happens because the rc.d script does something very simple: stop;
> start. This is correct, but stop doesn't do what it should. When stop
> returns, postgres may not have fully stopped for some reason. start
> complains that postmaster is still running. After doing some testing, my
> hypothesis is this (i have no idea how postgres works intermally):
> 1. I run a bunch of inserts, create tables
> 2. I call postgres stop
> 3. one of the postgres "processes" stops.
> 4. the other processes are still trying to flush stuff onto the disk before
> they quit.
> 5. start is called, and it finds some "postmaster" processes, and thus says
> "postmaster is running".
> 6. the other processes finally are done and stop.
> Now there are no more postgres running.
> When i added a sleep 10 between stop / start, everything was fine. The
> "correct" solution would be for postgres stop to actually wait for the
> entire db to exit cleanly. BTW, i uncovered this via an automated install /
> configuration / population of a postgress database which involves a restart
> right after population of a database.
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
In response to
pgsql-hackers by date
|Next:||From: Peter Eisentraut||Date: 2001-04-24 15:08:15|
|Subject: Re: refusing connections based on load ... |
|Previous:||From: Mauricio Breternitz||Date: 2001-04-24 13:41:05|
|Subject: Re: concurrent Postgres on NUMA - howto ?|