Thread: Implementing an Index Access Method in PG 8.4

Hi *,
I have a question according to the implementation of a new index access method in Postgres. Is it necessary to
implementa new resource manager for XLog when I am trying to achieve a stable new index access method? 
I actually don't know how to register a new ressource manager (if I would have to). Is there a way to bypass this using
somekind of "generic" resource manager that needs some kind of standardized input values, or do I have to do this
manually?
Actually my main problem here is, that I am just doing the implementation of some examples of index structures, just
basicthings to test what is to be done when implementing the stuff. However I found, that all the currently available
structuresin the source distribution do have their own recovery functionality using own resource managers. Thus I
thoughtthat I will probably have to add support for this, too, but I don't know exactly if it is really necessary (and,
asI already mentioned, how this would be possible). 

Best regards,
    Carsten Kropf

On Tue, Feb 23, 2010 at 10:00 AM, Carsten Kropf <ckropf2@fh-hof.de> wrote:
> I have a question according to the implementation of a new index access method in Postgres. Is it necessary to
implementa new resource manager for XLog when I am trying to achieve a stable new index access method? 
>

It's not currently possible to register a new recovery manager for a
module built outside the Postgres source tree. What's happened in the
past is new index methods weren't recoverable (after a database crash
indexes had to be rebuilt) but when they were integrated into the
Postgres source tree adding recoverability was a major piece of that
integration.

There's been some talk about allowing modules to register new recovery
managers but in the past it gets stuck on where to store information
about the recovery manager since the database tables aren't available.
And on how to guarantee that the backup database and the original
database have the same idea of which recovery manager is which.

--
greg

Ok, thanks so far.
The main question for me now is how to support all the XLog stuff in my own access method. I cannot set it up using the
WALrecovery procedure. So, what do I have to insert when doing a XLogInsert for example? I don't know which values to
putin there or doesn't it just matter, based on the fact that no recovery will be done at all? How do I register to the
XLogcomponent in order to achieve some message that an index recreation has to be done by the user? 
Actually, I have looked at the code provided by the backend index methods (like GiST or btree) and copied some of the
codeand adopted it to my wishes. So, now, I am totally confused how to set up a page properly without knowing how to
putdata in using XLog components. Could anybody please give me a hint how to achieve this? 
Am I able to use the XLog stuff at all?

Best regards
    Carsten Kropf
Am 23.02.2010 um 11:21 schrieb Greg Stark:

> On Tue, Feb 23, 2010 at 10:00 AM, Carsten Kropf <ckropf2@fh-hof.de> wrote:
>> I have a question according to the implementation of a new index access method in Postgres. Is it necessary to
implementa new resource manager for XLog when I am trying to achieve a stable new index access method? 
>>
>
> It's not currently possible to register a new recovery manager for a
> module built outside the Postgres source tree. What's happened in the
> past is new index methods weren't recoverable (after a database crash
> indexes had to be rebuilt) but when they were integrated into the
> Postgres source tree adding recoverability was a major piece of that
> integration.
>
> There's been some talk about allowing modules to register new recovery
> managers but in the past it gets stuck on where to store information
> about the recovery manager since the database tables aren't available.
> And on how to guarantee that the backup database and the original
> database have the same idea of which recovery manager is which.
>
> --
> greg
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general