Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id 616A62E006B for ; Mon, 12 May 2008 17:57:22 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 87359-03 for ; Mon, 12 May 2008 17:57:07 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from alexis.jtlnet.com (alexis.jtlnet.com [69.36.9.81]) by developer.postgresql.org (Postfix) with ESMTP id DFA432E0032 for ; Mon, 12 May 2008 17:57:03 -0300 (ADT) Received: from [192.168.10.103] (cpe-075-177-177-228.nc.res.rr.com [::ffff:75.177.177.228]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by alexis.jtlnet.com with esmtp; Mon, 12 May 2008 16:55:12 -0400 id 0008BBA4.4828AEB0.00005EE1 Message-ID: <4828AF1D.7060405@dunslane.net> Date: Mon, 12 May 2008 16:57:01 -0400 From: Andrew Dunstan User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.12) Gecko/20071019 Fedora/1.0.9-3.fc6 pango-text SeaMonkey/1.0.9 MIME-Version: 1.0 To: PostgreSQL-development , "Simon Riggs" Subject: odd output in restore mode Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200805/384 X-Sequence-Number: 118383 I have just been working on setting up a continuous recovery failover system, and noticed some odd log lines, shown below. (Using 8.3). First note that our parsing of recovery.conf in xlog.c is pretty bad, and at least we need to document the quirks if it's not going to be fixed. log_restartpoints is said to be boolean, but when I set it to an unquoted true I got a fatal error, while a quoted 'on' sets it to false, as seen. Ick. What is more, I apparently managed to get the recovery server to lose a WAL file and hang totally by having a bad recovery.conf. Triple ick. Second, what is all this about .history files? My understanding is that they are not necessary, so surely we should try to stat them to see if they are present before trying to copy them. These lines are going to confuse a lot of people, I suspect (including me). Lastly, not quite related to this output, but in the same general area, should we have an option on pg_standby to allow removing the archive file after it has been restored? cheers andrew LOG: database system was interrupted; last known up at 2008-05-12 15:18:23 EDT LOG: starting archive recovery LOG: log_restartpoints = false LOG: restore_command = '../bin/pg_standby -t ../common_archive/failover ../common_archive %f %p %r ' cp: cannot stat `../common_archive/00000001.history': No such file or directory cp: cannot stat `../common_archive/00000001.history': No such file or directory cp: cannot stat `../common_archive/00000001.history': No such file or directory LOG: restored log file "0000000100000000000000A5.00000068.backup" from archive LOG: restored log file "0000000100000000000000A5" from archive LOG: automatic recovery in progress LOG: redo starts at 0/A50000B0 LOG: restored log file "0000000100000000000000A6" from archive LOG: restored log file "0000000100000000000000A7" from archive LOG: restored log file "0000000100000000000000A8" from archive LOG: restored log file "0000000100000000000000A9" from archive trigger file found LOG: could not open file "pg_xlog/0000000100000000000000AA" (log file 0, segment 170): No such file or directory LOG: redo done at 0/A9000068 LOG: restored log file "0000000100000000000000A9" from archive cp: cannot stat `../common_archive/00000002.history': No such file or directory cp: cannot stat `../common_archive/00000002.history': No such file or directory cp: cannot stat `../common_archive/00000002.history': No such file or directory LOG: selected new timeline ID: 2 cp: cannot stat `../common_archive/00000001.history': No such file or directory cp: cannot stat `../common_archive/00000001.history': No such file or directory cp: cannot stat `../common_archive/00000001.history': No such file or directory LOG: archive recovery complete LOG: database system is ready to accept connections LOG: autovacuum launcher started