Re: recovery after interrupt in the middle of a previous recovery

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Or Kroyzer <orkroyzer(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: recovery after interrupt in the middle of a previous recovery
Date: 2010-05-26 14:04:59
Message-ID: 11647.1274882699@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Or Kroyzer <orkroyzer(at)gmail(dot)com> writes:
> I am using postgres 8.3.1,

... you really ought to be using 8.3.something-recent ...

> and have implemented warm standby very much like
> the one described in the high availability documentation on this site.
> It seems to work well except for this problem: I've had a case where the
> postgresql server was interrupted while in recovery (I think it was a user
> interrupt, the log sais:

> . LOG: received fast shutdown request
> LOG: archive recovery complete
> FATAL: terminating connection due to administrator command
> LOG: startup process (PID 6033) exited with exit code 1
> LOG: aborting startup due to startup process failure

> And after that, pg doesn't go through the recovery script provided in
> recovery.conf, and doesn't manage to come up. The log sais:

> LOG: database system was interrupted while in recovery at log time
> 2010-05-26 02:00:03 IDT
> HINT: If this has occurred more than once some data might be corrupted and
> you might need to choose an earlier recovery target.
> LOG: could not open file "pg_xlog/000000CA0000000A0000006D" (log file 10,
> segment 109): No such file or directory
> LOG: invalid primary checkpoint record
> LOG: could not open file "pg_xlog/000000CA0000000A0000006D" (log file 10,
> segment 109): No such file or directory
> LOG: invalid secondary checkpoint record
> PANIC: could not locate a valid checkpoint record
> LOG: startup process (PID 8081) was terminated by signal 6: Aborted
> LOG: aborting startup due to startup process failure

Hmm. Try putting back your recovery.conf file --- it will have been
renamed at the point where "archive recovery complete" was printed.
This example suggests that we might be doing that too early.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message paladine 2010-05-26 14:16:53 reducing postgresql disk space
Previous Message paulo matadr 2010-05-26 13:46:00 Help on update.