On Mon, 2008-09-15 at 10:47 +0100, Gregory Stark wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
>
> > On Sat, 2008-09-13 at 10:59 +0300, Heikki Linnakangas wrote:
> >
> >> The 2nd use case, however, I find pretty unconvincing. I can't think of
> >> a good example of that. Anything that needs to define its own resource
> >> manager is very low-level stuff, and probably needs to go into the core
> >> anyway.
> >
> > New indexes are a big one, but I listed others also.
> >
> > Indexes have always been able to be added dynamically. Now they can be
> > recovered correctly as well.
>
> Hm, so currently if you want to add a new indexam you can't just insert into
> pg_am and make them recoverable. You basically have to build in your new index
> access method into Postgres with the new rmgr. That is annoying and a problem
> worth tackling.
Agreed.
> But I'm a bit worried about having this be an external plugin. There's no way
> to looking at a WAL file to know whether it will be recoverable with the
> plugins available. Worse, there's a risk you could have a plugin but not the
> *right* plugin.
That risk was discussed and is handled in the plugin. You are limited to
only insert data into WAL that has a current plugin that says it will
handle redo for that type.
> Perhaps this could be tackled simply by having startup insert
> a record listing all the rmgr's in use with identifying information and their
> version numbers.
Non-standard plugins in use are listed when in use, so we can all see
what's going on. Plugins can issue their own startup messages if they
choose, with version numbers and other details.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
