On Mon, Jun 13, 2011 at 08:21:05AM -0400, Robert Haas wrote: > On Mon, Jun 13, 2011 at 1:12 AM, Noah Misch <n...@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... -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
