Re: corrupt pages detected by enabling checksums - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: corrupt pages detected by enabling checksums
Date
Msg-id 1367437236.2188.48.camel@jdavis
Whole thread Raw
In response to Re: corrupt pages detected by enabling checksums  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: corrupt pages detected by enabling checksums  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Wed, 2013-05-01 at 20:06 +0100, Simon Riggs wrote:
> >> Why aren't we writing just one WAL record for this action?

...

> >
> > I thought about that, too.  It certainly seems like more than we want
> > to try to do for 9.3 at this point.  The other complication is that
> > there's a lot of conditional logic here.

...

> Looks easy. There is no additional logic for checksums, so there's no
> third complexity.
> 
> So we either have
> * cleanup info with vismap setting info
> * cleanup info only
> 
> which is the same number of WAL records as we have now, just that we
> never emit 2 records when one will do.

What if we only set PD_ALL_VISIBLE and the VM bit, and make no other
changes? Right now, that generates no WAL for the heap page (unless
checksums are enabled, of course), which means no full page images for
the heap pages.

I think we have to special-case that somehow, and I believe that's the
conditional logic that Robert is referring to.

That being said, there may be a simpler way to achieve the same result,
and that may be what you have in mind.

Regards,Jeff Davis





pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: corrupt pages detected by enabling checksums
Next
From: Bruce Momjian
Date:
Subject: Re: Recovery target 'immediate'