On 04.12.2010 10:22, jes...@krogh.cc wrote:
Den 4 Dec 2010 kl. 08:48 skrev Heikki
Linnakangas<heikki.linnakan...@enterprisedb.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
