Re: Two Phase Commit WAS: Re: Two weeks to feature freeze
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
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, Pennsylvania 19073
Josh Berkus <josh@agliodbs.com> 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 work while it's holding locks
for the not-quite-committed transaction.
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.
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.
regards, tom lane
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 get in touch with CJ Date and see what he
has to say about it; but I don't care that much, except from a "Postgres
marketability" perspective.
Perhaps the people on this list who are pushing 2PC could do the ground work?
I'd suggest starting with the collected works of CJ Date and Hugh Darwin, and
contacting them if it's not already in a book.
--
-Josh Berkus
Aglio Database Solutions
San Francisco
Import Notes
Resolved by subject fallback
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 of distributed transactions supported by many third party
components -- that I'm aware of -- to the point where it is a part of
the Java Spec on dealing with distributed transactions.
- 2PC isn't very good in a number of circumstances, as such PostgreSQL
should avoid its use when PostgreSQL has a choice in the matter -- like
communication with other PostgreSQL servers.
This is a case of learning to speak Japanese because all of the people
you want to talk with only speak Japanese. It simply doesn't matter how
good Esperanto is.
--
Rod Taylor <rbt@rbt.ca>
PGP Key: http://www.rbt.ca/rbtpub.asc
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) is the only
implementation of distributed transactions supported by many third party
components -- that I'm aware of -- to the point where it is a part of
the Java Spec on dealing with distributed transactions.- 2PC isn't very good in a number of circumstances, as such PostgreSQL
should avoid its use when PostgreSQL has a choice in the matter -- like
communication with other PostgreSQL servers.This is a case of learning to speak Japanese because all of the people
you want to talk with only speak Japanese. It simply doesn't matter how
good Esperanto is.
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 protocol. The only relevance of this thread, as I see it, is
whether or not core will stomach an XA-compatible 2PC implementation
in the backend. If not, then is Satoshi Nagayasu in vain? That was
what I "sensed" in the original thread 6 months ago, that the 2PC work
being done by Satoshi Nagayasu was going to be allowed to die on the vine.
Mike Mascari
mascarm@mascari.com
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 support as described by the X/Open group) is the only
implementation of distributed transactions supported by many third party
components -- that I'm aware of -- to the point where it is a part of
the Java Spec on dealing with distributed transactions.- 2PC isn't very good in a number of circumstances, as such PostgreSQL
should avoid its use when PostgreSQL has a choice in the matter -- like
communication with other PostgreSQL servers.This is a case of learning to speak Japanese because all of the people
you want to talk with only speak Japanese. It simply doesn't matter how
good Esperanto is.
Agreed --- other db's have it, and people ask for it, so we should just
do our best and document the limitations.
--
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, Pennsylvania 19073
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:
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, Pennsylvania 19073---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
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 protocol. The only relevance of this thread, as I see it, is
I'm no expert in this area, but XA seems to be the choice for Java based
Transaction Servers, so at very least the JDBC guys will want to have
the ability to fake XA.
whether or not core will stomach an XA-compatible 2PC implementation
in the backend. If not, then is Satoshi Nagayasu in vain? That was
No, it's not in vain to add 2PC (XA-compatible was his interest at the
time) into the backend.
What is debatable is whether the PostgreSQL folks will implement a
replication system based on it.
what I "sensed" in the original thread 6 months ago, that the 2PC work
being done by Satoshi Nagayasu was going to be allowed to die on the vine.
It is difficult work, but is no less useful than nested transactions
will be. A certain segment of the user-base will be jumping up and down
when they get them, myself included.
--
Rod Taylor <rbt@rbt.ca>
PGP Key: http://www.rbt.ca/rbtpub.asc
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 more of them will put in
the dozens of hours required to make it reliable.
Josh,
you cannot put something that requires an FE/BE protocol change, ON
COMMIT extra work plus ON RESTART extra work into contrib.
The interim solution to Tom's concern is "ask the operator". His entire
point is based on the fact that there is no way to let the systems
figure out what's right in the case they lost communication and don't
know why. And for a system that just misses IP packets, there is no way
to figure out if it's just that someone tripped over the cable or if the
other building got nuked.
To figure out what happened was never the goal for the ARPA project.
Their goal was to continue communication as long as there is a possible
path. If that's gone, you're on your own ... sorry!
I think 2PC is of no use for things like replication with takeover on
failure in mind. At least it'd cause a major hickup in the system, and
since failurs tend to oscillate, I don't want to be anywhere close when
that collaborative throwup starts. But I do think that there is value in
distributed transactions. Well ... I *know* that there is.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #