On 04.12.2010 10:22, Jesper@Krogh.cc wrote:
> Den 4 Dec 2010 kl. 08:48 skrev Heikki Linnakangas<heikki.linnakangas@enterprisedb.com>:
>> If you WAL-log the visibility map changes after-the-fact, it doesn't solve the race condition we're struggling with:
thevisibility map change might hit the disk before the PD_ALL_VISIBLE to the heap page. If you crash, you can end up
witha situation where the PD_ALL_VISIBLE flag on the heap page is not set, but the bit in the visibility map is. Which
causesserious 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
thevisibility bit is cleared but the map bit change does not happen due to a crash. Then at wal replay time you restore
themap 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
similarlooking 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