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

From Simon Riggs
Subject Re: corrupt pages detected by enabling checksums
Date
Msg-id CA+U5nMJK79DNikAMdZE6eL7roz0Zu6-9ZBVCnGzcHH559=NcGA@mail.gmail.com
Whole thread Raw
In response to Re: corrupt pages detected by enabling checksums  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: corrupt pages detected by enabling checksums  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
On 1 May 2013 20:40, Jeff Davis <pgsql@j-davis.com> wrote:

>> 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.

The only place I see that code path is when we clear up a heap page
that is empty.

Is that what you meant?

Empty pages are pretty rare, so I guess I meant that we should just
get rid of the vismap update when we see that. Since we're adding the
block straught back into the fsm, it won't stay all visible for very
long.



Bottom line is: is there a problem there, or not?
If there's not, I'm happy. If there is, then do we have another plan
than making this into one WAL record, so it is atomic?
And presumably y'all want me to fix it.

--Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Commit subject line
Next
From: Andrew Dunstan
Date:
Subject: Re: Commit subject line