On Tue, Jul 26, 2011 at 6:36 PM, Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
