Re: Remaining beta blockers

On Fri, May  3, 2013 at 10:19:42PM -0400, Bruce Momjian wrote:
> 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.

OK, how are we for bata packaging on Monday?  I don't see how we can do
that until we decide on how to handle unlogged materialized views.

Can someone summarize what we have considered for a meta-page as the
first page in the past?  Have they always been things we couldn't
recording in the catalogs, or things we didn't want in the catalogs,
e.g. visibility/hint bits?

If we would eventually want the materialized information in the system
catalogs rather than on the first heap page, or recorded as the size of
the help file, I suggest we just remove anything that depends on it and
move to beta.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +