Re: corrupt pages detected by enabling checksums
От | Jeff Davis |
---|---|
Тема | Re: corrupt pages detected by enabling checksums |
Дата | |
Msg-id | 1367436691.2188.39.camel@jdavis обсуждение исходный текст |
Ответ на | Re: corrupt pages detected by enabling checksums (Robert Haas <robertmhaas@gmail.com>) |
Список | 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 по дате отправления: