On Mon, Jun 13, 2011 at 4:04 PM, Noah Misch <n...@leadboat.com> wrote: > 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...
I see your point. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
