Re: crash-safe visibility map, take four - Mailing list pgsql-hackers

On 30.03.2011 06:24, 高增琦 wrote:

Should we do full-page write for visibilitymap all the time?
Now, when clear visiblitymap, there is no full-page write for vm
since we don't save buffer info in insert/update/delete's log.

The full-page write is used to protect pages from disk failure. Without it,
1) set vm: the vm bits that should be set to 1 may still be 0
2) clear vm: the vm bits that should be set to 0 may still be 1
Are these true? Or the page is totally unpredictable?

Not quite. The WAL replay will set or clear vm bits, regardless of full page writes. Full page writes protect from torn pages, ie. the problem where some operations on a page have made it to disk while others have not. That's not a problem for VM pages, as each bit on the page can be set or cleared individually. But for something like a heap page where you have an offset in the beginning of the page that points to the tuple elsewhere on the page, you have to ensure that they stay in sync, even if you don't otherwise care if the update makes it to disk or not.

Another question:
To address the problem in
http://archives.postgresql.org/pgsql-hackers/2010-02/msg02097.php
, should we just clear the vm before the log of insert/update/delete?
This may reduce the performance, is there another solution?

Yeah, that's a straightforward way to fix it. I don't think the performance hit will be too bad. But we need to be careful not to hold locks while doing I/O, which might require some rearrangement of the code. We might want to do a similar dance that we do in vacuum, and call visibilitymap_pin first, then lock and update the heap page, and then set the VM bit while holding the lock on the heap page.