On Tue, Jul 26, 2011 at 6:36 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> Now, as you say, it seems really, really
> difficult to hit that in practice, but I don't see a way of getting
> rid of the theoretical possibility without either (1) a spinlock or
> (2) a fence. (Of course, on x86, the fence could be optimized down to
> a compiler barrier.) I guess the question is "should we worry about
> that?".
Perhaps the answer lies in a different direction altogether?
Let me ask a few questions to stimulate a different solution
* Can we do this using an active technique (e.g. signals) rather than
a passive one (reading a counter?)
* Can we partition the sinval lock, so we have multiple copies? That
increases the task for those who trigger an invalidation, but will
relieve the pressure for most readers.
* Can we put the sinval info in a different place? e.g. inside each
lock partition.
* Why do we have a different mechanism for cache invalidation
internally (sinval) to the one we offer externally (LISTEN/NOTIFY)?
Why don't we have just one?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
