> 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.
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. 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.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's PostGIS support!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
No comments:
Post a Comment