Re: standard interfaces for replication providers

From: alfranio correia junior <alfranio(at)lsd(dot)di(dot)uminho(dot)pt>
To: Markus Schiltknecht <markus(at)bluegap(dot)ch>
Cc: Jose Orlando Pereira <jop(at)lsd(dot)di(dot)uminho(dot)pt>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: standard interfaces for replication providers
Date: 2006-08-08 18:23:08
Message-ID: 44D8D68C.8050408@lsd.di.uminho.pt
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Browne 2006-08-08 18:24:47 Re: 8.2 features status
Previous Message Markus Schiltknecht 2006-08-08 18:08:52 Re: standard interfaces for replication providers