Postgres Hot Standby. How or when does the recovery db move recovery.conf to recovery.done? - Mailing list pgsql-general

From Dhaval Shah
Subject Postgres Hot Standby. How or when does the recovery db move recovery.conf to recovery.done?
Date
Msg-id 565237760703202325x1dea150er5734d7a298ec53b7@mail.gmail.com
Whole thread Raw
Responses Re: Postgres Hot Standby. How or when does the recovery db move recovery.conf to recovery.done?  ("Merlin Moncure" <mmoncure@gmail.com>)
List pgsql-general
Resending.

I have a "hot" standby. Now, if the primary fails
how do I tell the secondary that come out of recovery mode and move
the recovery.conf to recovery.done and start the db. I mean, what
error code shall I return?

If I return a non-zero error code (1), I get the following result [from
serverlog]:

====
00000001000000000000001B pg_xlog/RECOVERYXLOG
LOG:  restored log file "00000001000000000000001B" from archive
00000001000000000000001C pg_xlog/RECOVERYXLOG
[Main: Triggering Recovery!!!] <---- My script detected that it needs
to trigger recovery...
LOG:  could not open file "pg_xlog/00000001000000000000001C" (log file
0, segment 28): No such file or directory
LOG:  redo done at 0/1B000070
00000001000000000000001B pg_xlog/RECOVERYXLOG
Main: Triggering Recovery!!! <--- My script is called again and the
script says trigger recovery
PANIC:  could not open file "pg_xlog/00000001000000000000001B" (log
file 0, segment 27): No such file or directory
LOG:  startup process (PID 32167) was terminated by signal 6
LOG:  aborting startup due to startup process failure
====

This is what my script is doing:

if ( triggerRecovery() ) {
   print "Main: Triggering Recovery!!! \n";
   return 1;
}

So, the question is, on detecting that the primary is down and to
trigger recovery, what error code shall I return? Or do I have to move
the recovery.conf to recovery.done myself and restart the db?

Regards
Dhaval

pgsql-general by date:

Previous
From: "Merlin Moncure"
Date:
Subject: Re: select progressive total
Next
From: "Anton Melser"
Date:
Subject: Re: "sniffing" postgres queries