>> The all_visible_cleared flag is included in the WAL record of the insert (or update or delete). Partial page writes are not a problem, because we >> always fetch the VM page and clear the bit, regardless of the LSN on the VM page.
Two things a) First, my understanding of checkpoint is that it flushes all the pages, that got changed below a particular LSN. If we are not having a LSN in the visibility map, how we will be sure, that a visibility map page is getting flushed/not? With the following approach, i can see only one issue. If the heap page gets written and checkpointed and the visibility map doesn't get synced during the checkpoint, then there is an issue. Can you please explain me, how we get the assurance? b) Even if we have a contention issue, Visibility map is a solution for a considerable number of database scenarios. But it should not become a default package. A table, with no chance of index-only scans should not incur the extra overhead of crash safe visibility maps. Those tables should be sparred from this extra overhead, as they don't have index only scans. Gokul.
