Tom, You nailed it right in the head! My bad... My exit code was causing the problem. Once I changed it to 1 the recovery mode exited and the database came up:
waiting for file: 0000000100000000000000F2 --- trigger found --- --- exiting recovery mode --- exiting with 1 LOG: could not open file "pg_xlog/0000000100000000000000F2" LOG: redo done at 0/F1000070 file: 0000000100000000000000F1 path: pg_xlog/RECOVERYXLOG LOG: restored log file "0000000100000000000000F1" from archive LOG: archive recovery complete LOG: database system is ready Thanks to all who contributed to this thread - much obliged. Cheers, ~george -----Original Message----- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Thursday, June 28, 2007 10:16 PM To: George Wilk Cc: [email protected] Subject: Re: [ADMIN] aborting startup due to startup process failure "George Wilk" <[EMAIL PROTECTED]> writes: > I am running a warm standby server, which executes the following command in > a recovery mode: > [ when done: ] > exit 133 Did you pick that number out of a hat? Postgres thinks it means that the recovery command died horribly, and abandons the recovery as a safety measure. (Per Single Unix Spec, this exit code from a shell script would ordinarily mean that some program the shell called died with a signal 5.) Use "exit 1" or some low number like that to signal ordinary failure to find the requested xlog file. Numbers larger than about 125 mean catastrophic failure of the recovery command. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
