On Sun, Jun 12, 2011 at 9:23 PM, Noah Misch <noah@leadboat.com> wrote:
>> I haven't reviewed
>> your patch in detail, but is there a way we can encapsulate the
>> knowledge of the invalidation system down inside the sinval machinery,
>> rather than letting the heap code have to know directly about the
>> counter? Perhaps AIV() could return true or false depending on
>> whether any invalidation messages were processed, or somesuch.
>
> I actually did it exactly that way originally. The problem was the return value
> only applying to the given call, while I wished to answer a question like "Did
> any call to AcceptInvalidationMessages() between code point A and code point B
> process a message?" Adding AcceptInvalidationMessages() calls to code between A
> and B would make the return value test yield a false negative. A global counter
> was the best thing I could come up with that avoided this hazard.
Oh, interesting point. What if AcceptInvalidationMessages returns the
counter? Maybe with typedef uint32 InvalidationPositionId or
something like that, to make it partially self-documenting, and
greppable.
Taking that a bit further, what if we put that counter in
shared-memory? After writing new messages into the queue, a writer
would bump this count (only one process can be doing this at a time
because SInvalWriteLock is held) and memory-fence. Readers would
memory-fence and then read the count before acquiring the lock. If it
hasn't changed since we last read it, then don't bother acquiring
SInvalReadLock, because no new messages have arrived. Or maybe an
exact multiple of 2^32 messages have arrived, but there's probably
someway to finesse around that issue, like maybe also using some kind
of memory barrier to allow resetState to be checked without the lock.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company