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 implement a 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 some kind 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 basic things to test what is to be done when implementing the stuff. However I found, that all the currently available structures in the source distribution do have their own recovery functionality using own resource managers. Thus I thought that I will probably have to add support for this, too, but I don't know exactly if it is really necessary (and, as I 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 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
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:
Show quoted text
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 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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general