Re: Pluggable Indexes - Mailing list pgsql-hackers

On Fri, 2009-01-23 at 10:33 -0500, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
> > On Thu, 2009-01-22 at 18:45 -0500, Tom Lane wrote:
> >> There are other recent examples of proposed hooks that in fact
> >> failed to be useful because of some oversight or other, and it was
> >> not until we insisted on seeing a live use of the hooks that this
> >> became apparent.
> 
> > In the current case, index APIs are already well known, so that API is
> > unlikely to be a problem. The actual "rmgr plugin" API is very simple,
> > since its intention is only to add or edit entries onto the internal
> > RmgrTable (in memory) after which everything is well defined already.
> 
> Right, the WAL-record-processing API is not really at issue, since it's
> been proven internally to the core code.  My concern is with the other
> part, namely exactly how are we going to identify and install additional
> rmgrs.  There was substantial debate about that when it first came up,
> so you're not likely to convince me that it's such an open-and-shut case
> as to not need supporting evidence.

I hear your objection and will answer it, for the record at least.

We can load arbitrary code into any normal backend. I just want to be
able to do the same with the startup process. It can't be much of a
discussion since the API is essentially just the same as _PG_init(), or
shmem_startup_hook.

We took the risk with planner hook, and missed something. We took the
risk with RequestAddinShmemSpace() and missed something. There wasn't
any backlash or problem as a result though and we haven't even
backpatched the additional hooks. They were inspired additions. Why is
such a simple hook in Startup such a big deal? What would be wrong in
fixing any problem in the next release, just as we've done in the other
examples?

If we didn't already have chapters in the manual on index extensibility
I would have to agree. We could regard this patch as fixing an oversight
in index extensibility, presumably when WAL was created.

The patch is just
* a hook in StartupXLOG to allow loading arbitrary code into Startup
* some slight redefinition of RmgrTable to allow arbitrary code to add
or modify the contents of that table of functions. (Being able to modify
the table is an not necessary for index extensions, but is for other
uses).
* some safeguards people requested

Buggy code in shmem_startup_hook could do just as much damage at startup
or in a crash situation, but we have no safeguards there and nobody has
said a single word against that.

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support