Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 44DEC64FD30 for ; Tue, 18 Nov 2008 15:07:06 -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 41512-04 for ; Tue, 18 Nov 2008 15:07:02 -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 232BD64FC8B for ; Tue, 18 Nov 2008 15:06:56 -0400 (AST) Received: from localhost ([204.209.205.55]) by priv-edmwes25.telusplanet.net (InterMail vM.7.08.03.00 201-2186-126-20070710) with ESMTP id <20081118190650.BZPJ3630.priv-edmwes25.telusplanet.net@localhost> for ; Tue, 18 Nov 2008 12:06:50 -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 11:06:50 -0800 Message-ID: <1227035210.4923124a948e9@legacywebmail.telus.net> Date: Tue, 18 Nov 2008 11:06:50 -0800 From: Mischa Sandberg 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> <1227026844.4922f19ce4c77@legacywebmail.telus.net> <22317.1227032425@sss.pgh.pa.us> In-Reply-To: <22317.1227032425@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/105 X-Sequence-Number: 30759 Quoting Tom Lane : > Mischa Sandberg writes: > > Quoting Tom Lane : > >> 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. The systems are under erratic load, due to concurrent cpu and diskio spikes around start-up time. 1-2 secs is not enough to be a guarantee :-( Probably not explaining the issues well; caught between two constraints that aren't really pg's problem; and wide clusters with automated admin, variable hardware and spikes of db restarts are no doubt an oddball edge case. There are workarounds; was hoping for something clean and obvious (to all but me). Switching back to tailing the log files and moving on. Thanks everyone. -- Engineers think that equations approximate reality. Physicists think that reality approximates the equations. Mathematicians never make the connection.