Re: Implementing an Index Access Method in PG 8.4
От | Carsten Kropf |
---|---|
Тема | Re: Implementing an Index Access Method in PG 8.4 |
Дата | |
Msg-id | 8FEEA126-334A-44B6-8ED4-0752A468CF61@fh-hof.de обсуждение исходный текст |
Ответ на | Re: Implementing an Index Access Method in PG 8.4 (Greg Stark <gsstark@mit.edu>) |
Список | 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 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
В списке pgsql-general по дате отправления: