Re: Global Deadlock Information

> > (2) Use the global wait-for graph to detect a global deadlock.
>
> Can you please elaborate on the replication solution that needs such a
> global wait-for graph? Why do you need a global graph, if you replicate
> all of your transaction anyway? Does that global graph imply a global
> abort decision as well?
>
> IMO a local wait-for graph is absolutely sufficient. The problem is just
> that different nodes might reach different decisions on how to resolve
> the deadlock. But if you replicate to all nodes, they will all be able
> to "see" the deadlock, no?
>
> > http://en.wikipedia.org/wiki/Deadlock#Distributed_deadlock
>
> That very article states:
>
> "In a Commitment ordering based distributed environment (including the
> Strong strict two-phase locking (SS2PL, or rigorous) special case)
> distributed deadlocks are resolved automatically by the atomic
> commitment protocol (e.g. two-phase commit (2PC)), and no global
> wait-for graph or other resolution mechanism are needed."
>
> And the issue with "phantom deadlocks" doesn't really excite me either,
> so I'd rather like not having to deal with such things.

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. For example, we could send SELECT queries to each DB odes
without any consideration of CO. This will achieve higher concurrent
processing with a price of occasional "global dealock", still this
will be better solution in mostly-readonly-transaction environment.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

> > I don't think the callback function is needed to replace
> > the current deadlock resolution feature,
>
> Obviously this wish list item needs more discussion. It seems we want
> two rather different things, then.
>
> How does your replication solution cope with the current deadlock
> resolver? How do you prevent it aborting
>
> > but I agree we need a consensus how we could avoid
> > the global deadlock situation in the cluster.
>
> How do you get to the situation where you have a global deadlock, but
> not a local one? That seems to imply that you are not replicating locks
> to all nodes.
>
> How do you think Postgres core could help with determining such global
> deadlocks? That seems more like a solution-specific thing to me.
>
> Are we even talking about the same level of locking, namely regular,
> heavy-weight locks (as per the storage/lmgr/README)?
>
> Kind Regards
>
> Markus Wanner
>
>
> --
> Sent via pgsql-cluster-hackers mailing list (pgsql-cluster-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-cluster-hackers