Re: Crash safe visibility map vs hint bits

On 04.12.2010 10:22, Jesper(at)Krogh(dot)cc wrote:
> Den 4 Dec 2010 kl. 08:48 skrev Heikki Linnakangas<heikki(dot)linnakangas(at)enterprisedb(dot)com>:
>> If you WAL-log the visibility map changes after-the-fact, it doesn't solve the race condition we're struggling with: the visibility map change might hit the disk before the PD_ALL_VISIBLE to the heap page. If you crash, you can end up with a situation where the PD_ALL_VISIBLE flag on the heap page is not set, but the bit in the visibility map is. Which causes serious issues later on.
>
> My imagination is probably not as good, but if you at time A wallog the complete map and at A+1 you update a tuple so the visibility bit is cleared but the map bit change does not happen due to a crash. Then at wal replay time you restore the map from time A and if the tuple change at A+1 is represented in the wal stream the you also update the visibility map. This is the situation where the heap tuple hit disk but the map is left in a broken state? Or is it a different similar looking situation?

The problem is when a bit is *set* in the visibility map. Clearing a bit
is not a problem, we already handle that reliably. If you set the flag
on the heap page and set the bit on the visibility map page, and you
don't emit a WAL record on either of those operations, the VM page might
be flushed to disk before the heap page.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com