start / stop scripts question

You will find that that script is not distributed by us.

[ Charset ISO-8859-1 unsupported, converting... ]

Hi,

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.

Thanx.

-rchit

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://www.postgresql.org/search.mpl

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

who is it distributed by then? it was on the postgres ftp mirror sites, so
it probably can't be redhat. I have found workarounds, so its not a big
deal, but... Also, i wonder what else is different from this package from
the "real" source distribution. I am sorry if this has been discussed or
explained in the past before, but i cannot find this info in a FAQ or know
what keywords to use if i want to search on the mailing list :).

-rchit

-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
Sent: Tuesday, April 24, 2001 7:28 AM
To: Rachit Siamwalla
Cc: PostgreSQL Development
Subject: Re: [HACKERS] start / stop scripts question

You will find that that script is not distributed by us.

[ Charset ISO-8859-1 unsupported, converting... ]

Hi,

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.

Thanx.

-rchit

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://www.postgresql.org/search.mpl

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

I would like to know myself. I just did a recursive grep of the entire
PostgreSQL tree and don't see it. My guess is that it is part of the
RPM. Not sure who to report that to. I know Lamar Owen works on it,
but I don't know if he is the contact.

[ Charset ISO-8859-1 unsupported, converting... ]

who is it distributed by then? it was on the postgres ftp mirror sites, so
it probably can't be redhat. I have found workarounds, so its not a big
deal, but... Also, i wonder what else is different from this package from
the "real" source distribution. I am sorry if this has been discussed or
explained in the past before, but i cannot find this info in a FAQ or know
what keywords to use if i want to search on the mailing list :).

-rchit

-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
Sent: Tuesday, April 24, 2001 7:28 AM
To: Rachit Siamwalla
Cc: PostgreSQL Development
Subject: Re: [HACKERS] start / stop scripts question

You will find that that script is not distributed by us.

[ Charset ISO-8859-1 unsupported, converting... ]

Hi,

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.

Thanx.

-rchit

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://www.postgresql.org/search.mpl

-- 
Bruce Momjian                        |  http://candle.pha.pa.us
pgman@candle.pha.pa.us               |  (610) 853-3000
+  If your life is a hard drive,     |  830 Blythe Avenue
+  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian wrote:

I would like to know myself. I just did a recursive grep of the entire
PostgreSQL tree and don't see it. My guess is that it is part of the
RPM. Not sure who to report that to. I know Lamar Owen works on it,
but I don't know if he is the contact.

Yes, that would be me. I saw the original message come through, just
haven't had a chance to reply to it.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11