Skip site navigation (1) Skip section navigation (2)

Re: trying to run PITR recovery

From: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Warren Little" <Warren(dot)Little(at)MeridiasCapital(dot)com>,<pgsql-admin(at)postgresql(dot)org>
Subject: Re: trying to run PITR recovery
Date: 2007-03-30 15:34:51
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-admin
On Sun, 2007-03-25 at 20:57 -0400, Tom Lane wrote:
> Warren Little <Warren(dot)Little(at)MeridiasCapital(dot)com> writes:
> > I'm testing my PITR recovery procedures and something doesn't look  
> > right.
> > The following is from the logs upon starting postgres with  
> > recovery.conf file in place
> > @ 2007-03-23 05:57:33 MDTLOG:  restored log file  
> > "000000010000011A000000FD" from archive
> > @ 2007-03-23 05:57:35 MDTLOG:  incorrect resource manager data  
> > checksum in record at 11A/FD492B20
> > @ 2007-03-23 05:57:35 MDTLOG:  redo done at 11A/FD492210
> > My concern is that there were many more logfiles to be played  
> > following "00000010000011A000000FD"
> > (ie 000000010000011E0000005C) yet it appears the recovery stop at  
> > that point and called it good.
> Perhaps you have a bad copy of that particular log segment file?
> The "incorrect checksum" failure is normal in certain circumstances
> (eg, where the system crashes partway through writing out a large
> WAL record), which is why the code treats it as indicating the end
> of WAL.  But in this case it looks more like corrupt data ...


I think there is a problem here. If we stop before the end of logs we
should be incrementing the timeline id.

I'm not going to think about it right now, but I'll think on that next
week. Not the most likely problem we'll ever see, I grant you.

  Simon Riggs             

In response to


pgsql-admin by date

Next:From: Tom LaneDate: 2007-03-30 16:14:22
Subject: Re: Performance on views
Previous:From: Simon RiggsDate: 2007-03-30 15:31:46
Subject: Re: trying to run PITR recovery

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group