On Sat, Aug 20, 2011 at 4:57 AM, Gokulakannan Somasundaram
> <gokul...@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
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??
Thanks,
Gokul.
