Skip site navigation (1) Skip section navigation (2)

Re: Global Deadlock Information

From: Markus Wanner <markus(at)bluegap(dot)ch>
To: Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>
Cc: satoshi(dot)nagayasu(at)gmail(dot)com, pgsql-cluster-hackers(at)postgresql(dot)org
Subject: Re: Global Deadlock Information
Date: 2010-02-15 05:54:58
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-cluster-hackers

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 
talking about.

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
> usefull.

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.


Markus Wanner

In response to

pgsql-cluster-hackers by date

Next:From: Greg SmithDate: 2010-02-27 23:49:38
Subject: Cluster feature: Start/stop archiving at runtime
Previous:From: Greg SmithDate: 2010-02-13 06:21:56
Subject: Cluster feature: API into the Parser / Parser as an independent module

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group