On Tue, Jul 26, 2011 at 05:05:15PM -0400, Tom Lane wrote: > Noah Misch <n...@2ndquadrant.com> writes: > > That's the theoretical risk I wished to illustrate. Though this appears > > possible on an abstract x86_64 system, I think it's unrealistic to suppose > > that > > a dirty cache line could persist *throughout* the issuance of more than 10^9 > > invalidation messages on a concrete implementation. > > Dirty cache line, maybe not, but what if the assembly code commands the > CPU to load those variables into CPU registers before doing the > comparison? If they're loaded with maxMsgNum coming in last (or at > least after resetState), I think you can have the problem without any > assumptions about cache line behavior at all. You just need the process > to lose the CPU at the right time.
True. If the compiler places the resetState load first, you could hit the anomaly by "merely" setting a breakpoint on the next instruction, waiting for exactly MSGNUMWRAPAROUND messages to enqueue, and letting the backend continue. I think, though, we should either plug that _and_ the cache incoherency case or worry about neither. -- Noah Misch http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
