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
|
Список | 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 по дате отправления: