Re: pg_regress.sh startup failure patch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jason Tishler <jason(at)tishler(dot)net>
Cc: Pgsql-Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: pg_regress.sh startup failure patch
Date: 2002-01-03 21:55:45
Message-ID: 27629.1010094945@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Jason Tishler <jason(at)tishler(dot)net> writes:
> I just checked one of my old favorites, "The UNIX Programming
> Environment," by Kernighan and Pike, 1984. It appears that "until"
> is understood by the Bourne shell back then, so its use should be OK.

Yeah, that's what I thought. I ended up applying the attached patch;
this not only avoids the timing problem but has more reliable detection
of postmaster startup failure than the original code.

regards, tom lane

*** src/test/regress/pg_regress.sh.orig Sun Sep 16 12:11:11 2001
--- src/test/regress/pg_regress.sh Thu Jan 3 16:52:05 2002
***************
*** 353,358 ****
--- 353,379 ----
"$bindir/postmaster" -D "$PGDATA" -F $postmaster_options >"$LOGDIR/postmaster.log" 2>&1 &
postmaster_pid=$!

+ # Wait till postmaster is able to accept connections (normally only
+ # a second or so, but Cygwin is reportedly *much* slower). Don't
+ # wait forever, however.
+ i=0
+ max=60
+ until "$bindir/psql" $psql_options template1 </dev/null 2>/dev/null
+ do
+ i=`expr $i + 1`
+ if [ $i -ge $max ]
+ then
+ break
+ fi
+ if kill -0 $postmaster_pid >/dev/null 2>&1
+ then
+ : still starting up
+ else
+ break
+ fi
+ sleep 1
+ done
+
if kill -0 $postmaster_pid >/dev/null 2>&1
then
echo "running on port $PGPORT with pid $postmaster_pid"
***************
*** 363,371 ****
echo
(exit 2); exit
fi
-
- # give postmaster some time to pass WAL recovery
- sleep 3

else # not temp-install

--- 384,389 ----

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2002-01-03 22:00:42 Re: pg_regress.sh startup failure patch
Previous Message Ross Thomas 2002-01-03 20:38:37 Re: Patch for ODBC driver (look for odbc.ini in more than