On Mon, Jun 13, 2011 at 08:21:05AM -0400, Robert Haas wrote:
> On Mon, Jun 13, 2011 at 1:12 AM, Noah Misch <noah@leadboat.com> wrote:
> > This probably would not replace a backend-local counter of processed messages
> > for RangeVarLockRelid()'s purposes. ?It's quite possibly a good way to reduce
> > SInvalReadLock traffic, though.
> I was imagining one shared global counter, not one per backend, and
> thinking that each backend could do something like:
>
> volatile uint32 *the_global_counter = &global_counter;
> uint32 latest_counter;
> mfence();
> latest_counter = *the_global_counter;
> if (latest_counter != previous_value_of_global_counter || myprocstate->isReset)
> really_do_it();
> previous_value_of_global_counter = latest_counter;
>
> I'm not immediately seeing why that wouldn't work for your purposes as well.
That takes us back to the problem of answering the (somewhat rephrased) question
"Did any call to AcceptInvalidationMessages() between code point A and code
point B call really_do_it()?" in a way not prone to breaking when new calls to
AcceptInvalidationMessages(), perhaps indirectly, get added. That's what the
local counter achieved. To achieve that, previous_value_of_global_counter would
need to be exposed outside sinval.c. That leaves us with a backend-local
counter updated in a different fashion. I might be missing something...
