I think we are talking across each other here. I'm having Postgres-R in
mind, while I'm not sure what kind of clustering solution you are
Tatsuo Ishii wrote:
> I'm not sure if I understand the concept of CO at all, but for me it
> seems sometimes transaction control which does not use CO is
Well, it depends a bit on what they mean by commit ordering. For
Postgres-R, an atomic broadcast protocol takes care of "ordering"
commits. I guess that counts as a commit ordering protocol.
> For example, we could send SELECT queries to each DB odes
> without any consideration of CO.
SELECTs are mostly read-only, so I don't quite understand what those
have to do with the order of commits.
> This will achieve higher concurrent
> processing with a price of occasional "global dealock", still this
> will be better solution in mostly-readonly-transaction environment.
Please elaborate on what kind of replication solution you have in mind
and how that generates global deadlocks.
In Postgres-R, only writing transactions need to be replicated. So only
their commits need ordering. All possibly global deadlocks will turn
into local deadlocks, so I'm only concerned with consistent resolution
of multiple local deadlocks.
I'd appreciate to hear your needs. Very possibly, there still is a huge
amount of overlap.
In response to
pgsql-cluster-hackers by date
|Next:||From: Greg Smith||Date: 2010-02-27 23:49:38|
|Subject: Cluster feature: Start/stop archiving at runtime |
|Previous:||From: Greg Smith||Date: 2010-02-13 06:21:56|
|Subject: Cluster feature: API into the Parser / Parser as an independent