Re: standard interfaces for replication providers - Mailing list pgsql-hackers

From Jim C. Nasby
Subject Re: standard interfaces for replication providers
Date
Msg-id 20060809185609.GK40481@pervasive.com
Whole thread Raw
In response to Re: standard interfaces for replication providers  (Markus Schiltknecht <markus@bluegap.ch>)
Responses Re: standard interfaces for replication providers
Re: standard interfaces for replication providers
List pgsql-hackers
On Wed, Aug 09, 2006 at 07:33:35AM +0000, Markus Schiltknecht wrote:
> Hello Alfranio,
> 
> alfranio correia junior wrote:
> >Of course not...
> >It is impossible to build a replication system entirely by only using
> >triggers...
> 
> Hm, I don't think it's impossible, just unpractical. Anyway, if you say 
> so yourself, I really doubt the use of GAPI. If you need to create your 
> own hooks anyway beside GAPI, why use GAPI at all? Better have one kind 
> of 'hooking' (i.e. with a dynamically loaded library).
Why reinvent the wheel for everything if there was an interface that
offered some of the needed functionality? Maybe PostgreSQL-R is simply
too deep in the database for any of this to be useful, but I'm 99%
certain that Slony could make use of some of this stuff, such as a hook
on tuples being written out. Likewise, if there were hooks for WAL
records and a way to inject WAL info into a backend it probably wouldn't
be too hard to build WAL-based replication on top of that. Heck, PITR
could probably be refactored to use such hooks.

One of the great things about Oracle is that they expose a hell of a lot
of the technology they use to build features like replication; ie: take
a look at DBMS_*.

> >But definitely, there is a set of common requirements among a variety of
> >replication systems. Moreover, such requirements are also useful to
> >other systems as well.
> 
> So far, they are only partly usable for replication. I never looked into 
> materialized views or anything else that would benefit from such triggers.
> 
> Regards
> 
> Markus
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
> 

-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461


pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: new job
Next
From: "Jim C. Nasby"
Date:
Subject: Re: An Idea for planner hints