We've begun rolling 8.3 out to our remote sites and have already had to do two recoveries using the PITR backup techniques. (Neither was any fault of PostgreSQL. One server had a second drive in a RAID 5 array fail before the hot spare finished taking the place of the first one. The other ran into problems running the scripts related to an upgrade of our application software, and we decided to roll back and leave them on the old release until we sorted out the problems.) We've noticed a couple things which seem to merit comment. In both cases it seemed to take longer to apply the WAL files during the recovery process than we're used to from 8.2 I don't have hard numbers, but before I spent time investigating I thought I would ask here if that is already a known issue. In the rollback from the bad application software update, we wanted to restore up to the point where we shut down user access to the database, and before we started running the update scripts. We had an "at" job scheduled to kick this off at 17:00, so the recovery.conf file had this line: recovery_target_time = '2008-10-16 17:00:00.0' The log shows this: [2008-10-16 23:03:43.146 CDT] 19951 LOG: restored log file "000000010000000100000056" from archive [2008-10-16 23:04:26.005 CDT] 19951 LOG: recovery stopping before abort of transaction 77627, time 2008-10-16 17:00:23.205347-05 [2008-10-16 23:04:26.006 CDT] 19951 LOG: redo done at 1/56FD4918 [2008-10-16 23:04:26.006 CDT] 19951 LOG: last completed transaction was at log time 2008-10-16 17:00:23.205347-05 The line that gives me pause is "last completed transaction". Did it really replay a transaction from from more than 23 seconds after the recovery_target_time, or was that the first transaction it didn't replay? -Kevin -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
