Re: crash-safe visibility map, take five

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: crash-safe visibility map, take five
Дата
Msg-id 1308790434.4717.93.camel@jdavis-ux.asterdata.local
обсуждение исходный текст
Ответ на Re: crash-safe visibility map, take five  (Noah Misch <noah@leadboat.com>)
Ответы Re: crash-safe visibility map, take five  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
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.

Regards,Jeff Davis




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: Coding style point: "const" in function parameter declarations
Следующее
От: Robert Haas
Дата:
Сообщение: Re: crash-safe visibility map, take five