Message-ID: <4D93277B.7060503@enterprisedb.com>
Date: Wed, 30 Mar 2011 15:52:11 +0300
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; fi-FI;
	rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11
MIME-Version: 1.0
To: =?UTF-8?B?6auY5aKe55Cm?= <pgf00a@gmail.com>
CC: Simon Riggs <simon@2ndquadrant.com>, Jesper Krogh <jesper@krogh.cc>,
	Robert Haas <robertmhaas@gmail.com>,
	pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: crash-safe visibility map, take four
References: <AANLkTino+UehSpXz+-ZP4Q58mSjW_JHx7Q4GUiPfRbC2@mail.gmail.com>
	<4D89902C.7000004@krogh.cc>
	<AANLkTi=nfHFf4VR-gSMNxaVwPzEJGwCGHZYxNW20ocoL@mail.gmail.com>
	<AANLkTik5V28HAGmKq0oX5K-HhKinB6BSHmN93EEa3Hu7@mail.gmail.com>
In-Reply-To: <AANLkTik5V28HAGmKq0oX5K-HhKinB6BSHmN93EEa3Hu7@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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