Re: A thought on Index Organized Tables

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