On 28.11.2012 06:27, Noah Misch wrote:
On Tue, Nov 27, 2012 at 10:08:12AM -0800, Jeff Janes wrote:
Doing PITR in 9.2.1, the system claims that it reached a consistent
recovery state immediately after redo starts.
This leads to it various mysterious failures, when it should instead
throw a "requested recovery stop point is before consistent recovery
point" error.
(If you are unlucky, I think it might even silently start up in a
corrupt state.)
I observed a similar problem with 9.2. Despite a restore_command that failed
every time, startup from a hot backup completed. At the time, I suspected a
mistake on my part.
I believe this was caused by this little typo/thinko:
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -6763,7 +6763,7 @@ StartupXLOG(void)
/* Pop the error context stack */
error_context_stack = errcontext.previous;
- if (!XLogRecPtrIsInvalid(ControlFile->backupStartPoint)
&&
+ if (!XLogRecPtrIsInvalid(ControlFile->backupEndPoint)
&&
XLByteLE(ControlFile->backupEndPoint,
EndRecPtr))
{
/*
Normally, backupEndPoint is invalid, and we rely on seeing an
end-of-backup WAL record to mark the location. backupEndPoint is only
set when restoring from a backup that was taken from a standby, but
thanks to the above, recovery incorrectly treats that as end-of-backup.
Fixed, thanks for the report!
- Heikki
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
