From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Ben <bench(at)silentmedia(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: two phase commit |
Date: | 2007-07-19 22:42:50 |
Message-ID: | 1184884970.16532.125.camel@dogma.ljc.laika.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, 2007-07-19 at 15:13 -0700, Ben wrote:
> I'm reading the description of PREPARE TRANSACTION, and I see this:
>
> "...its state is fully stored on disk, and there is a very high
> probability that it can be committed successfully..."
>
> What corner case reduces 2pc from "guaranteed" to "very high probability"?
> Is the worry if somebody leaves transactions in a prepared state for
> weeks, only to find that deadlock issues has arrisen at final commit time?
>
You won't get a deadlock on COMMIT, because COMMIT doesn't acquire more
locks.
The failure cases for a 2PC transaction are (as I understand it)
catastrophic. That means either the transaction can be committed, or you
probably need to restore onto new hardware anyway.
2PC is useful when multiple databases are involved and your application
crashes. When the application comes back you can look at the prepared
transactions and decide whether to COMMIT PREPARED or ROLLBACK PREPARED
based on the information in the other databases involved.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Ben | 2007-07-19 22:49:02 | Re: two phase commit |
Previous Message | Tom Lane | 2007-07-19 22:34:55 | Re: two phase commit |