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.
