Josh Berkus wrote:
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 m
> I don't think it could have been said any better. There are a host of
> improvements on the standard 2PC protocol, including 3PC, multi-cast
> 2PC, and other variants both synchronous and asynchronous. But if
> PostgreSQL is going to work with XA, then it doesn't get to choose the
> TM or the pro
I second the agreement ... a 'reference implementation', of sorts, at
least gives someone to build on then starting right from scratch ...
On Mon, 23 Jun 2003, Bruce Momjian wrote:
>
> Agreed.
>
> ---
>
> Josh Berkus wrote
Rod Taylor wrote:
-- Start of PGP signed section.
> > Perhaps the people on this list who are pushing 2PC could do the ground work?
>
>
> - 2PC is better than a standard transaction when dealing with multiple
> servers as it can recover in some circumstances (but not all).
>
> - 2PC (XA suppor
Rod Taylor wrote:
>>Perhaps the people on this list who are pushing 2PC could do the ground work?
>
> - 2PC is better than a standard transaction when dealing with multiple
> servers as it can recover in some circumstances (but not all).
>
> - 2PC (XA support as described by the X/Open group)
> Perhaps the people on this list who are pushing 2PC could do the ground work?
- 2PC is better than a standard transaction when dealing with multiple
servers as it can recover in some circumstances (but not all).
- 2PC (XA support as described by the X/Open group) is the only
implementation o
Tom,
"Putting in "dozens of hours" is not the issue here --- the problem is
that there isn't any solution in sight, and I'm not eager to go down a
path that has an obvious dead end."
Well, I doubt we're breaking any new ground with this discussion. If I really
cared about this feature, I would
Josh Berkus <[EMAIL PROTECTED]> writes:
>> 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
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
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 th
10 matches
Mail list logo
