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 1367436691.2188.39.camel@jdavis
Whole thread Raw
In response to Re: corrupt pages detected by enabling checksums  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Wed, 2013-05-01 at 14:16 -0400, Robert Haas wrote:
> Now that I'm looking at this, I'm a bit confused by the new logic in
> visibilitymap_set().  When checksums are enabled, we set the page LSN,
> which is described like this: "we need to protect the heap page from
> being torn".  But how does setting the page LSN do that?  Don't we
> need to mark the buffer dirty or something like that?  Sorry if this
> is a dumb question.

The caller is supposed to dirty the heap page when setting
PD_ALL_VISIBLE. I thought I said that explicitly in the comments
somewhere, but now I don't see it.

It is slightly awkward to put the comment about the page being torn just
before setting the LSN. Feel free to move/remove/reword if you can think
of something better.

Because setting PD_ALL_VISIBLE does not write WAL by itself, my design
was to have it piggyback on the VM WAL record if checksums are turned
on. It would be nice to just use MarkBufferDirtyHint, but that does not
guarantee that the page will actually be marked dirty (see comments);
and we really need it to be properly marked dirty (otherwise we risk the
VM bit making it and the heap page not).

I also explored the idea of passing more options to MarkBufferDirty so
that we could force it to do what we want in each case, but decided
against it:

http://www.postgresql.org/message-id/1357798000.5162.38.camel@jdavis-laptop

Regards,Jeff Davis





pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Documentation epub format
Next
From: Jeff Davis
Date:
Subject: Re: corrupt pages detected by enabling checksums