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.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
