From: Jose Orlando Pereira <jop@lsd.di.uminho.pt>
Organization: http://gsd.di.uminho.pt/members/jop
To: pgsql-hackers@postgresql.org
Subject: Re: standard interfaces for replication providers
Date: Tue, 8 Aug 2006 22:51:24 +0100
User-Agent: KMail/1.9.3
Cc: Markus Schiltknecht <markus@bluegap.ch>,
 alfranio@lsd.di.uminho.pt
References: <44D30B31.2070403@lsd.di.uminho.pt>
	<200608071940.26750.jop@lsd.di.uminho.pt>
	<44D89EA5.5090703@bluegap.ch>
In-Reply-To: <44D89EA5.5090703@bluegap.ch>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200608082251.24329.jop@lsd.di.uminho.pt>

On Tuesday 08 August 2006 15:24, Markus Schiltknecht wrote:
>
> An API is always limiting.

Which is a good thing when you are not the one using it but the one committing 
to support it. :-)

> I still feel that I would need ways too many hooks. Especially when you
> consider advanced replication features such as data partitioning and
> remote query execution.

Indeed. We have not prototyped those features. Nonetheless, look at 
the "silly" query cache example in the distribution (search for 
QueryCache.java). It shows how the proposed hooks might be used to intercept 
a query and fake a result set, while at the same time executing some stuff 
locally. (Warning: this runs on Apache Derby only, as in PostgreSQL we'd need 
something like PL/J for server side JDBC.).

> What also worries me is the use of triggers. ISTM that using triggers is
> not deep enough in the database. In the above example, do I really want
> to fire a trigger every time the database needs to wake up a process? In
> PostgreSQL a trigger normally runs within a transaction. How do you work
> around that?

As Alfranio has pointed out in another message in this thread, these triggers 
are high level. We never consider some thing "trigger on lock acquire" (also 
because it also would hardly be portable). They certainly are more coarse 
grained than the standard on update stuff.

Furthermore, having on commit triggers running within transactional boundaries 
is very useful. Think about recording global commit order or global 
timestamps in the originating site after propagation.

-- 
Jose Orlando Pereira