Re: visibility maps

Pavan Deolasee wrote:
> On Thu, Dec 11, 2008 at 5:01 PM, Zdenek Kotala <Zdenek(dot)Kotala(at)sun(dot)com> wrote:
>> IIRC, Memory reading/writing is atomic operation. Only one CPU(hw thread)
>> can access to the same memory address(es)* in same time*. The question is
>> how compiler compile C code to assembler. But this code seems to me safe.
>
> Yeah, I think the code is safe because we are just reading a bit.

Right. I wonder if we should declare the char *map variable as volatile,
though. Shouldn't make a difference in practice, it's only used once in
the function, but it feels like the right thing to do given that it is
accessing a piece of memory without a lock.

> BTW, I wonder if we need to acquire EXCLUSIVE lock while writing the
> visibility map bit ? Since almost (8 * 8192) data blocks would map to
> the same visibility map page, the lock can certainly become a hot
> spot. I know we also update PageLSN during the set operation and that
> would require EXLUSIVE lock, but is that required for consistency
> given that the entire visibility map is just a hint ?

Yeah, if we accept that bits can be bogusly set. There is scenarios
where that can happen already, but they involve crashing, not during
normal operation and clean shut down. In the future, I'd like to move in
the direction of making the visibility map *more* reliable, not less,
ultimately allowing index-only-scans, so I'd rather not start relaxing that.

Only the first update to a page needs to clear the bit in the visibility
map, so I don't think it'll become a bottleneck in practice. Frequently
updated pages will never have the bit set in the visibility map to begin
with.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com