On 21.08.2011 07:41, Gokulakannan Somasundaram wrote:
> On Sat, Aug 20, 2011 at 4:57 AM, Gokulakannan Somasundaram
>
>> <gokul007@gmail.com> wrote:
>>> by your argument, if WALInserLock is held for 't' seconds, you should
>>> definitely be holding visibility map lock for more than time frame 't'.
>>
>> Nope, that's not how it works. Perhaps you should read the code.
>> See, e.g., heap_update().
>>
>> --
>>
> OK. I took a look at the patch you have supplied in
> http://postgresql.1045698.n5.nabble.com/crash-safe-visibility-map-take-five-td4377235.html
Here's the patch as it was committed:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=503c7305a1e379f95649eef1a694d0c1dbdc674a
> There is a code like this.
>
> {
> all_visible_cleared = true;
> PageClearAllVisible(BufferGetPage(buffer));
> + visibilitymap_clear(relation,
> + ItemPointerGetBlockNumber(&(heaptup->t_self)),
> +&vmbuffer);
> }
>
> Here, you are not making an entry into the WAL. then there is an assumption
> that the two bits will be in sync without any WAL entry. There is a chance
> that the visibility map might be affected by partial page writes, where
> clearing of a particular bit might not have been changed. And i am thinking
> a lot of such issues. Can you just explain the background logic behind
> ignoring the principle of WAL logging? What are the implemented principles,
> that protect the Visibility map pages??
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.
PS. Robert, the LOCKING section in the header comment of visibilitymap.c
is out-of-date: it claims that the VM bit is cleared after releasing the
lock on the heap page.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com