From: alfranio correia junior <alfranio@lsd.di.uminho.pt>
To: Markus Schiltknecht <markus@bluegap.ch>
Cc: Jose Orlando Pereira <jop@lsd.di.uminho.pt>
Cc: pgsql-hackers@postgresql.org
Subject: Re: standard interfaces for replication providers
Date: Tue, 08 Aug 2006 19:23:08 +0100
Message-ID: <44D8D68C.8050408@lsd.di.uminho.pt> (raw)
In-Reply-To: <44D89EA5.5090703@bluegap.ch>
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>
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.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: alfranio@lsd.di.uminho.pt, markus@bluegap.ch, jop@lsd.di.uminho.pt
Subject: Re: standard interfaces for replication providers
In-Reply-To: <44D8D68C.8050408@lsd.di.uminho.pt>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox