<br /><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204);
margin:0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The WAL record of the heap insert/update/delete contains a flag<br />
indicatingthat the visibility map needs to be updated too. Thus no need<br /> for a separate WAL record.<br /><div
class="im"><br/></div></blockquote></div><br />Heikki,<br /> Have you considered these cases?<br />a) The
currentWAL architecture makes sure that the WAL Log is written before the actual page flush( i believe ). But you are
changingthat architecture for Visibility maps. Visibility map might get flushed out before the corresponding WAL gets
written.I think you would then suggest full page writes here<br /> b) Say for a large table, you have multiple buffers
ofvisibility map, then there is a chance that one buffer gets flushed to the disk and the other doesn't. If the WAL
recordsare not in place, then this leads to a time inconsistent visibility map.<br /> c) If you are going to track all
theWAL linked with a buffer of visibility map, then you need to introduce another synchronization in the critical
path.<br/><br />May be i am missing something? I am asking these questions only out of curiosity. <br /><br
/>Thanks,<br/>Gokul.<br />
