On Mon, Jun 13, 2011 at 4:04 PM, Noah Misch <noah@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 <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...
I see your point.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
