From: Simon Riggs <simon@2ndQuadrant.com>
To: Gregory Stark <stark@enterprisedb.com>
Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>
Cc: pgsql-hackers@postgresql.org
Subject: Re: rmgr hooks and contrib/rmgr_hook
Date: Mon, 15 Sep 2008 11:14:29 +0100
Message-ID: <1221473669.3913.1257.camel@ebony.2ndQuadrant> (raw)
In-Reply-To: <87sks1oi4o.fsf@oxford.xeocode.com>
References: <20080901121833.4A18.52131E4D@oss.ntt.co.jp>
<1220345064.4371.275.camel@ebony.2ndQuadrant>
<20080902174613.76B2.52131E4D@oss.ntt.co.jp>
<1220348980.4371.316.camel@ebony.2ndQuadrant>
<14451.1220369969@sss.pgh.pa.us>
<1220372673.4371.465.camel@ebony.2ndQuadrant>
<48CB72C8.1070700@enterprisedb.com>
<1221470800.3913.1229.camel@ebony.2ndQuadrant>
<87sks1oi4o.fsf@oxford.xeocode.com>
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.com
PostgreSQL Training, Services and Support
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-patches@postgresql.org
Cc: simon@2ndQuadrant.com, stark@enterprisedb.com, heikki.linnakangas@enterprisedb.com, tgl@sss.pgh.pa.us, itagaki.takahiro@oss.ntt.co.jp, pgsql-hackers@postgresql.org
Subject: Re: rmgr hooks and contrib/rmgr_hook
In-Reply-To: <1221473669.3913.1257.camel@ebony.2ndQuadrant>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox