Message-ID: <44D89EA5.5090703@bluegap.ch>
Date: Tue, 08 Aug 2006 14:24:37 +0000
From: Markus Schiltknecht <markus@bluegap.ch>
User-Agent: Thunderbird 1.5.0.4 (X11/20060713)
MIME-Version: 1.0
To: Jose Orlando Pereira <jop@lsd.di.uminho.pt>
CC: pgsql-hackers@postgresql.org, alfranio@lsd.di.uminho.pt
Subject: Re: standard interfaces for replication providers
References: <44D30B31.2070403@lsd.di.uminho.pt>
	<200608041733.24228.jop@lsd.di.uminho.pt>
	<44D70EDA.9060602@bluegap.ch>
	<200608071940.26750.jop@lsd.di.uminho.pt>
In-Reply-To: <200608071940.26750.jop@lsd.di.uminho.pt>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

Jose Orlando Pereira wrote:
> Sorry, stuff was put twice in the zip file making it somewhat confusing. It is 
> in postgresql-g-0.1/javasrc/GordaInterfaces/docs/gapi.pdf or directly on the 
> web site at http://gorda.di.uminho.pt/download/reports/gapi.pdf.

Thank you. I've just had a quick glance at it.

> Can you point out why is it [limiting], given that it is admittedly quite close?

An API is always limiting. And if you have to change the API a lot, to 
fit your needs, what's the point in using it at all? Good APIs don't 
change a lot.

Even if it's quite close, I estimate the effort to port Postgres-R to 
use your API to be quite large. I.e. the first missing thing that came 
to my mind was the ordering of processes when waking them up after 
waiting for a lock. Postgres-R needs the processes to be woken up in the 
order of writeset arrival.

Now, I didn't see anything related in the patch, but the gapi.pdf has 
'Predictable Deadlock Handling' in it. I need to take another look...

> We'd rather discuss specific issues instead of the general topic of whether to 
> build APIs around them. We certainly are not married to the proposed 
> interfaces, although the functionality they capture does reflect our 
> experience with several algorithms.

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.

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?

I'm operating a level deeper with Postgres-R and really enjoy the 
freedom I have with C. Having to write a hook or trigger for every 
change in the database systems seems a lot of work, which I tend to 
postpone until such a thing is really needed.

Regards

Markus