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:tgl@sss.pgh.pa.us]
Sent: Thursday, June 28, 2007 10:16 PM
To: George Wilk
Cc: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] aborting startup due to startup process failure
"George Wilk" <gwilk@ellacoya.com> 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
