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
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 |