Re: Two Phase Commit WAS: Re: Two weeks to feature freeze

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Two Phase Commit WAS: Re: Two weeks to feature freeze
Date: 2003-06-23 16:00:59
Message-ID: 200306230900.59719.josh@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom,

> No. I want to know what the subordinate does when it's promised to
> commit and the co-ordinator never responds. AFAICS the subordinate
> is screwed --- it can't commit, and it can't abort, and it can't expect
> to make progress indefinitely on other work while it's holding locks
> for the not-quite-committed transaction.

AFAIK, MS SQL Server's two-phase commit works like this ... if both servers
prepare, and one crashes, the transaction is screwed up. Somewhat unreliable
considering the frequence with which MSSQL crashes, yet it seems to be good
enough for several companies to sell "solutions" based on it. (performance is
also appalling, but that's a different issue)

Anybody have a grasp of Oracle internals for 2PC?

Anyway, I would vote for a first implemenation for 2PC which addressed the
commit-then-crash issue in some expedient-but-not-reliable way, and putting
2PC in /contrib with a "not for production use" warning. Some people will
use it in production anyway, and hopefully one or more of them will put in
the dozens of hours required to make it reliable.

--
Josh Berkus
Aglio Database Solutions
San Francisco

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nailah Ogeer 2003-06-23 16:13:58 SHM_QUEUE
Previous Message Robert Treat 2003-06-23 14:52:17 Re: Two weeks to feature freeze