Received: from localhost (unknown [200.46.204.183])
	by mail.postgresql.org (Postfix) with ESMTP id DB63E64FCC7
	for <pgsql-admin-postgresql.org@mail.postgresql.org>;
	Tue, 18 Nov 2008 12:47:35 -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 10238-02 for
	<pgsql-admin-postgresql.org@mail.postgresql.org>;
	Tue, 18 Nov 2008 12:47:32 -0400 (AST)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from defout.telus.net (defout.telus.net [204.209.205.13])
	by mail.postgresql.org (Postfix) with ESMTP id 4F7C564FC8B
	for <pgsql-admin@postgresql.org>; Tue, 18 Nov 2008 12:47:31 -0400 (AST)
Received: from localhost ([204.209.205.55]) by priv-edmwes51.telusplanet.net
	(InterMail vM.7.08.03.00 201-2186-126-20070710) with ESMTP
	id <20081118164725.XLTG10956.priv-edmwes51.telusplanet.net@localhost>
	for <pgsql-admin@postgresql.org>; Tue, 18 Nov 2008 09:47:25 -0700
Received: from 209.17.179.1 ( [209.17.179.1])
	as user a3a18850@204.209.205.54 by legacywebmail.telus.net with HTTP;
	Tue, 18 Nov 2008 08:47:24 -0800
Message-ID: <1227026844.4922f19ce4c77@legacywebmail.telus.net>
Date: Tue, 18 Nov 2008 08:47:24 -0800
From: Mischa Sandberg <mischa_sandberg@telus.net>
To: pgsql-admin@postgresql.org
Subject: Re: Reliably determining whether the server came up 
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>
In-Reply-To: <20048.1227023982@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.1-cvs
X-Originating-IP: 209.17.179.1
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/100
X-Sequence-Number: 30754

Quoting Tom Lane <tgl@sss.pgh.pa.us>:

> Mischa Sandberg <mischa_sandberg@telus.net> writes:
> > Perhaps it's my "test for DB ready" that's the problem?
> 
> > + while pg_ctl status && ! psql -l; do sleep 1; done >/dev/null
> 2>&1
> 
> 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.

BTW the example with (start,status,psql,createlang) failing just
happened, to my surprise, on my dev box -- fairly fast and lightly
loaded. On loaded, unattended systems, it happened consistently.
............
In another vein, another place where there are consistent
failures is in the sequence:

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

The failure can happen on createdb ("template1 is busy")
or on <app>; and most frequently on the systems with overloaded disks.
My hacky response is to separate those steps with:

   psql -qc checkpoint template1

which consistently makes the problem go away; but what is
the problem, exactly, that this is tripping over??

Anyway, thanks for the comments.
-- 
Engineers think that equations approximate reality.
Physicists think that reality approximates the equations.
Mathematicians never make the connection.