On Sun, Jun 12, 2011 at 9:23 PM, Noah Misch <n...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
