Simon Riggs <[EMAIL PROTECTED]> 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. 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
