Gokulakannan Somasundaram wrote: > a) The current WAL architecture makes sure that the WAL Log is written > before the actual page flush( i believe ). But you are changing that > architecture for Visibility maps. Visibility map might get flushed out > before the corresponding WAL gets written.
Yes. When a bit is cleared, that's OK, because a cleared bit just means "you need to check visibility in the heap tuple". When a bit is set, however, it's important that it doesn't hit the disk before the corresponding heap page update. That's why visibilitymap_set() sets the LSN on the page. > b) Say for a large table, you have multiple buffers of visibility map, then > there is a chance that one buffer gets flushed to the disk and the other > doesn't. If the WAL records are not in place, then this leads to a time > inconsistent visibility map. Huh? > c) If you are going to track all the WAL linked with a buffer of visibility > map, then you need to introduce another synchronization in the critical > path. Double huh? I'd suggest that you take some time to read the code and comments in visibilitymap.c and the call sites of those functions, to get a better picture of how it works. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
