Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 85651650311 for ; Wed, 12 Nov 2008 18:05:45 -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 25865-01-3 for ; Wed, 12 Nov 2008 18:05:38 -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 A9BB7650225 for ; Wed, 12 Nov 2008 18:05:37 -0400 (AST) Received: from localhost ([204.209.205.55]) by priv-edmwes26.telusplanet.net (InterMail vM.7.08.03.00 201-2186-126-20070710) with ESMTP id <20081112220535.DYDO2706.priv-edmwes26.telusplanet.net@localhost> for ; Wed, 12 Nov 2008 15:05:35 -0700 Received: from 209.17.179.1 ( [209.17.179.1]) as user a3a18850@204.209.205.54 by legacywebmail.telus.net with HTTP; Wed, 12 Nov 2008 14:05:35 -0800 Message-ID: <1226527535.491b532f4c45e@legacywebmail.telus.net> Date: Wed, 12 Nov 2008 14:05:35 -0800 From: Mischa Sandberg To: pgsql-admin@postgresql.org Subject: Reliably determining whether the server came up 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/67 X-Sequence-Number: 30721 I've been trying to work out a reliable script to determine, after pg_ctl start, that the server is done attempting to come up, and that it has either succeeded OR FAILED. This is for several hundred unattended appliance-type servers, currently on PG 8.0 but soon to be on 8.3 Haven't found anything in the archives. I want to determine success/failure without time-outs, since: the db is restarted every time a server gets an upgrade, and it can get several upgrades in a batch, and the cpu/disk load during an upgrade is highly variable; a restart with no recovery may still require as much as a minute to get to 'ready'. We also need to restart the server several hundred times in our in-house system tests. So pg_ctl -w start is not an option, even if the timeout were configurable to under a minute. The best I have that doesn't involve modifying pg_ctl is: # Hand-compute $NEXT_LOG from postgresql.conf # parameters (log_directory) and (log_filename). # Replace %S format with a '??' wildcard (yech). $ TEMP_LOG=/tmp/pg.$PGPORT.log $ touch $NEXT_LOG >$TEMP_LOG $ FROM=`awk 'END {print NR+1}' $NEXT_LOG` $ pg_ctl start -s -l $TEMPLOG $ while tail +$FROM $NEXT_LOG | ! egrep -hw 'FATAL|PANIC|DETAIL|ready|shutting|^postmaster cannot' $TEMP_LOG -; do sleep 1; done The nasty cases are when the server fails (exits) without being able to create its std log file (e.g. error in postgresql.conf). So I'm down to patching start_postmaster in pg_ctl.c to use popen("... & echo $!") instead of system("... &"), then make test_postmaster_connection do a kill(0,pid) if PQsetdbLogin fails. Any suggestions appreciated. -- Engineers think that equations approximate reality. Physicists think that reality approximates the equations. Mathematicians never make the connection.