Received: from localhost (unknown [200.46.204.183])
	by mail.postgresql.org (Postfix) with ESMTP id 2A1C065028A
	for <pgsql-admin-postgresql.org@mail.postgresql.org>;
	Tue, 18 Nov 2008 14:20:32 -0400 (AST)
Received: from mail.postgresql.org ([200.46.204.86])
	by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024)
	with ESMTP id 32643-06 for
	<pgsql-admin-postgresql.org@mail.postgresql.org>;
	Tue, 18 Nov 2008 14:20:27 -0400 (AST)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by mail.postgresql.org (Postfix) with ESMTP id 6F1126502E4
	for <pgsql-admin@postgresql.org>; Tue, 18 Nov 2008 14:20:26 -0400 (AST)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id mAIIKPNS022318;
	Tue, 18 Nov 2008 13:20:25 -0500 (EST)
To: Mischa Sandberg <mischa_sandberg@telus.net>
cc: pgsql-admin@postgresql.org
Subject: Re: Reliably determining whether the server came up 
In-reply-to: <1227026844.4922f19ce4c77@legacywebmail.telus.net> 
References: <1226527535.491b532f4c45e@legacywebmail.telus.net>
	<491F1861.4060403@reedyriver.com>
	<1226780945.491f3111e22de@legacywebmail.telus.net>
	<1226781115.22056.1.camel@jd-laptop.pragmaticzealot.org>
	<49200BD8.4060703@reedyriver.com>
	<1226989027.49225de368848@legacywebmail.telus.net>
	<20048.1227023982@sss.pgh.pa.us>
	<1227026844.4922f19ce4c77@legacywebmail.telus.net>
Comments: In-reply-to Mischa Sandberg <mischa_sandberg@telus.net>
	message dated "Tue, 18 Nov 2008 08:47:24 -0800"
Date: Tue, 18 Nov 2008 13:20:25 -0500
Message-ID: <22317.1227032425@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none
X-Spam-Level: 
X-Archive-Number: 200811/104
X-Sequence-Number: 30758

Mischa Sandberg <mischa_sandberg@telus.net> writes:
> Quoting Tom Lane <tgl@sss.pgh.pa.us>:
>> I'd bet that the pg_ctl status part is failing.  I get exit status 1
>> from it if there's no server running.

> Yes, that was part of the problem with the original startup script;
> postmaster hadn't even gotten as far as writing postmaster.pid,
> I guess. But pg_ctl status returning 1 could also mean that that the
> server had come up, hit a critical problem and exited. Hence my problem;
> this has to detect server failure, reliably, as well.

You could sleep for a second or so *before* you start looking for the
pidfile.

> In another vein, another place where there are consistent
> failures is in the sequence:

>    createlang ... -d template1 plpgsql
>    createdb $PGDATABASE
>    <app>

This should be fixed in 8.3 and up.  In older releases about all you
can do is delay a second or so to let the old backend exit.

			regards, tom lane