Re: crash-safe visibility map, take five
От | Jeff Davis |
---|---|
Тема | Re: crash-safe visibility map, take five |
Дата | |
Msg-id | 1308796801.5357.23.camel@jdavis-ux.asterdata.local обсуждение исходный текст |
Ответ на | Re: crash-safe visibility map, take five (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: crash-safe visibility map, take five
|
Список | pgsql-hackers |
On Wed, 2011-06-22 at 21:53 -0400, Robert Haas wrote: > On Wed, Jun 22, 2011 at 8:53 PM, Jeff Davis <pgsql@j-davis.com> wrote: > > On Thu, 2011-06-16 at 23:17 -0400, Noah Misch wrote: > >> 2. In the words of a comment added by the patch: > >> * The critical integrity requirement here is that we must never end up with > >> * a situation where the visibility map bit is set, and the page-level > >> * PD_ALL_VISIBLE bit is clear. If that were to occur, then a subsequent > >> * page modification would fail to clear the visibility map bit. > >> It does this by WAL-logging the operation of setting a vm bit. This also has > >> the benefit of getting vm bits set correctly on standbys. > > > > In the same function, there is also the comment: > > > > "We don't bump the LSN of the heap page when setting the visibility > > map bit, because that would generate an unworkable volume of > > full-page writes. This exposes us to torn page hazards, but since > > we're not inspecting the existing page contents in any way, we > > don't care." > > > > It would be nice to have a comment explaining why that is safe with > > respect to the WAL-before-data rule. Obviously torn pages aren't much of > > a problem, because it's a single bit and completely idempotent. > > That's exactly what I was trying to explain in the comment you cite. > Feel free to propose a specific change... Well, I was a little unsure, but here's my attempt: The potential problems are: 1. Torn pages -- not a problem because it's a single bit and idempotent. 2. PD_ALL_VISIBLE bit makes it to disk before a WAL record representing an action that makes the page all-visible. Depending on what action makes a page all-visible: a. An old snapshot is released -- not a problem, because if there is a crash all snapshots are released. b. Cleanup action on the page -- not a problem, because that will create a WAL record and update the page's LSN before setting the PD_ALL_VISIBLE. First of all, is that correct? Second, are there other cases to consider? Regards,Jeff Davis
В списке pgsql-hackers по дате отправления: