Re: [HACKERS] Dynamically adding index types (was GIT indexes)

2007-09-21 Thread Simon Riggs 
On Wed, 2007-09-19 at 10:37 -0400, Tom Lane wrote: 
 Simon Riggs [EMAIL PROTECTED] writes:
  We're able to dynamically add AMs in the way you suggest, but there is
  no way to alter the RMgrTable to either add a new RM or re-assign one of
  the unused RMs.
 
 Hmmm...

  1. Remove the Const in front of RmgrTable in rmgr.c. That would allow
  re-assignment of the two existing unused RMs.
 
 Useless, as there's no way for an add-on AM to cause the value to be
 changed before recovery begins.

OK, sounds like the only way is to have a dedicated plug-in. 


if (resource_manager_hook)
   set RmgrTable in plugin
else
   normal static definition (but no longer Const)

...or variations of the above depending upon whether we want to allow
redefining existing Rmgrs - not something I personally want.

Plus something to say xlog record found for unknown Rmgr.

Plus changes to all places that refer to RM_MAX_ID and replace with a
global value of RmgrTableEntries.

We can then get rid of the two reserved Rmgr values...


Will that do it?


-- 
  Simon Riggs
  2ndQuadrant  http://www.2ndQuadrant.com


---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] Dynamically adding index types (was GIT indexes)

2007-09-19 Thread Tom Lane 
Simon Riggs [EMAIL PROTECTED] writes:
 We're able to dynamically add AMs in the way you suggest, but there is
 no way to alter the RMgrTable to either add a new RM or re-assign one of
 the unused RMs.

Hmmm...

 1. Remove the Const in front of RmgrTable in rmgr.c. That would allow
 re-assignment of the two existing unused RMs.

Useless, as there's no way for an add-on AM to cause the value to be
changed before recovery begins.

 2. Create a new catalog table pg_rm and some brief machinery to populate
 the RmgrTable from pg_rm. That would allow dynamically adding RMs.

Also useless --- what if pg_rm is damaged or missing?  Even if it's
there, how would recovery be able to tell which rows are valid?  We
certainly don't want it trying to do pg_clog probes.

regards, tom lane

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org