Re: Make relation_openrv atomic wrt DDL
Noah Misch <noah@leadboat.com>
From: Noah Misch <noah@leadboat.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Simon Riggs <simon@2ndquadrant.com>, pgsql-hackers@postgresql.org, heikki.linnakangas@enterprisedb.com
Date: 2011-06-13T20:04:29Z
Lists: pgsql-hackers
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...