Re: Catalog/Metadata consistency during changeset extraction from wal

Hi,

On Thursday, June 21, 2012 04:39:21 PM Simon Riggs wrote:
> On 21 June 2012 12:41, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> > 3)
> > Multi-Versioned catalog
> >
> > Below are two possible implementation strategies for that concept
> >
> > Advantages:
> > * Decoding is done on the master in an asynchronous fashion
> > * low overhead during normal DML execution, not much additional code in
> > that path
> > * can be very efficient if architecture/version are the same
> > * version/architecture compatibility can be done transparently by falling
> > back to textual versions on mismatch
> >
> > Disadvantages:
> > * decoding probably has to happen on the master which might not be what
> > people want performancewise
> >
> > 3a)
> > Change the system catalogs to be versioned
> >
> > Advantages.
> > * catalog access is easy
> > * might be interesting for other users
> >
> > Disadvantages:
> > * catalog versioning is complex to implement
> > * space overhead for all users, even without using logical replication
> > * I can't see -hackers signing off
>
> Hmm, there's all sorts of stuff mixed up there in your description.
Sure, it tried to compress a complex topic discussed in a long thread ;)

> ISTM we should maintain a lookup table on target system that has the
> minimal required information on it.
You need just about the whole catalog because the *_out procs might need to
lookup types, operators and such again.
Unless you want to rewrite those functions you need to provide a normal
execution environment.

I don't see how your idea works because of that? Am I missing something?

Yes, that would be easier if we didn't want to support conversion to text and
similar, but I don't see that flying. And even if it would be acceptable you
would need to have enough information to construct a btree ScanKey which means
you already need a lot of the catalogs.

> There is no need to version the whole catalog. (Complete overkill - I
> would oppose it ;-)
Hey, that originally was your idea :P. But I definitely agree, its not a good
idea.

Greetings,

Andres
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services