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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html