Re: visibility maps

From: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: visibility maps
Date: 2008-12-11 11:31:27
Message-ID: 4940FA0F.50008@sun.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas napsal(a):
> Pavan Deolasee wrote:
>> /*
>> * We don't need to lock the page, as we're only looking at a single
>> bit.
>> */
>> result = (map[mapByte] & (1 << mapBit)) ? true : false;
>>
>>
>> Isn't this a dangerous assumption to make ? I am not so sure that even
>> a bit
>> can be read atomically on all platforms.
>
> Umm, what non-atomic state could the bit be in? Half-set, half-cleared?
> Or do you think that if some other bit in proximity is changed, the
> other bit would temporarily flip 0->1->0, or something like that? I
> don't think that should happen.
>

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. I think
we use same principle for TransactionID?

Zdenek

* Wide is architecture dependent. and of course it depends on alignment. I'm not
sure how x86 CPUs read nonalignment memory. But if you enable this on SPARC it
is handled in software thru TRAP handlers and it is not really atomic. But in
our case we use byte access which is safe everywhere.

** IIRC, some AMD64 processors allows to disable cache coherence check, but it
not used in standard OS, and we can ignore it.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2008-12-11 11:37:36 Refactoring SearchSysCache + HeapTupleIsValid
Previous Message Jonah H. Harris 2008-12-11 11:10:25 Re: COCOMO & Indians