Re: Implementing an Index Access Method in PG 8.4

From: Carsten Kropf <ckropf2(at)fh-hof(dot)de>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Implementing an Index Access Method in PG 8.4
Date: 2010-02-23 10:53:33
Message-ID: 8FEEA126-334A-44B6-8ED4-0752A468CF61@fh-hof.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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 WAL recovery procedure. So, what do I have to insert when doing a XLogInsert for example? I don't know which values to put in 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 XLog component 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 code and adopted it to my wishes. So, now, I am totally confused how to set up a page properly without knowing how to put data 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(at)fh-hof(dot)de> wrote:
>> I have a question according to the implementation of a new index access method in Postgres. Is it necessary to implement a 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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Magnus Hagander 2010-02-23 10:56:53 Re: [GENERAL] pg_dump: aborting because of version mismatch
Previous Message Net Tree Inc. 2010-02-23 10:34:11 Re: [GENERAL] pg_dump: aborting because of version mismatch