Re: Two-phase commit

Tom Lane wrote:
> Oliver Jowett <oliver(at)opencloud(dot)com> writes:
>
>>Tom Lane wrote:
>>
>>>Well, the question is how long must the individual databases retain
>>>state with which to answer "recover" requests.
>
>>As I understand it, you don't need to keep state for committed txns,
>
> I think that's clearly wrong:
>
> TM --> DB: COMMIT PREPARED foo
>
> DB does it and forgets gid foo
>
> TM crashes and restarts
>
> TM --> DB: what's the state of foo?
>
> DB --> TM: go away, never heard of it
>
> I suppose you could code the TM to treat this as meaning "it was
> committed"

I believe that is exactly what the TM does. Can you take a look at
http://pybsddb.sourceforge.net/ref/xa/build.html (it's fairly brief) and
point out any holes in the logic there?

> but I think the folly of that is obvious.

It's fragile in the face of badly implemented TMs or resources, but
other than that it seems OK to me. What was the problem you were
thinking of in particular?

> Yeah, there's another set of issues there. Personally I always thought
> that 2PC was a fundamentally broken concept, because it's got so many
> squirrelly cases where the guarantees you thought you were buying with
> all this overhead vanish into thin air.

You can get around some of the issues via 3PC but that has even *more*
overhead. And noone actually implements it as far as I know :)

2PC is OK if you are only expecting it to handle certain failure modes,
e.g. no byzantine failures, no loss of stable storage, no extended
communication failures.

In general, the two-army problem just sucks..

-O