On Sat, May 4, 2013 at 03:04:33AM +0100, Greg Stark wrote:
> On Fri, May 3, 2013 at 5:49 PM, Bruce Momjian <bruce@momjian.us> wrote:
> > Yes, I think the big question is how much information do we want per
> > relation that we don't need in the system tables.
>
> It's not that we don't need it in the system tables. It's that there's
> some state that we *can't* have in the system tables because we need
> it to be accessible without access to the catalog or we need to be
> able to change it on a standby.
>
> But note that this all sounds very similar to the global temp table
> discussion a while ago. I think we're gong to need some infrastructure
> for table state that isn't transactional and it will make sense to
> solve that with something general that we can then depend on for lots
> of things. If I had to guess it would look more like a cached copy of
> the pg_class row or the whole relcache entry rather than an entirely
> independent structure.
Well, the big question is whether this state _eventually_ will need to
be accessible from SQL, so we might as well add code to allow crash
recovery to write to system tables.
Things like how fresh the materialized view is certainly should be
accessible via SQL and transactional.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
