Agreed.
---------------------------------------------------------------------------
Josh Berkus wrote:
> 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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
>
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073