Message-ID: <44D8D68C.8050408@lsd.di.uminho.pt>
Date: Tue, 08 Aug 2006 19:23:08 +0100
From: alfranio correia junior <alfranio@lsd.di.uminho.pt>
User-Agent: Thunderbird 1.5.0.5 (X11/20060728)
MIME-Version: 1.0
To: Markus Schiltknecht <markus@bluegap.ch>
CC: Jose Orlando Pereira <jop@lsd.di.uminho.pt>, pgsql-hackers@postgresql.org
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>
	<44D89EA5.5090703@bluegap.ch>
In-Reply-To: <44D89EA5.5090703@bluegap.ch>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Markus Schiltknecht wrote:
> 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...
If I correctly understood your idea, a priority mechanism would be
enough to do so and different applications might exploit it.
Most likely, we need this to apply remote transactions. However, note
that a priority mechanism is not only of interesting in the field of
replication systems but it might be used to improve performance for
instance.

Take a look at the ideas presented in
http://www.cs.cmu.edu/~bianca/icde04.pdf

Unfortunately, our current "prototype" only provides two levels: high
priority or normal priority.
Definitely,  it should be improved and we are aware of that.

>
>> 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 think we are talking about different levels.... as I said a high
priority mechanism would be enough.
In this case, the API should provide only an interface to set the
priority of a transaction....
In our case, still unfinished and quite simple: "set transaction master"
but it could be easily transformed into "set transaction priority <n>".

Best regards,

Alfranio Junior.