On Wed, Jun 22, 2011 at 8:53 PM, Jeff Davis <pg...@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... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
