Pavan Deolasee wrote:
On Thu, Dec 11, 2008 at 5:01 PM, Zdenek Kotala <[EMAIL PROTECTED]> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
