On Thu, Oct 06, 2005 at 10:30:26AM -0500, Scott Marlowe wrote:
>
> Information Schema: MySQL's support of this looks fairly extensive.
But PostgreSQL's is pretty good, too, last I looked.
> Instance Manager: Uniquely MySQL. It allows things like starting and
> stopping the database remotely.
What does "Instance Manager" buy you that ssh doesn't? (For bonus
points, what does ssh get you that Instance Manager doesn't? Hint: I
have a Symbian UIQ phone. Google for "PuTTY".)
> XA Transactions: MySQL's are pretty primitive, and PostgreSQL's XA may
> not be much further ahead there. XA transactions need some form of
> management for partial transactions. MySQL's answer here was to just
> refuse to commit on any member if any other member failed to be prepared
> for commit. This is possibly the least useful implementation of XA
> there could be, as the primary reason I've seen for it is to allow an
> application to have n db servers, and to "kick one out" if it starts
> misbehaving and run on the remaining n-1 servers. Note that right now,
> PostgreSQL's XA has, as far as I know, no real conflict management. But
> I'm guessing PostgreSQL will have a better fleshed out XA interface
> before MySQL.
Well, to be fair, one of the Open Group's XA targets is actual
distributed data sets, and not just reliability through redundancy.
So MySQL's implementation appears to be enough to support the former
in some ways. What seems more troublesome to me is that if a machine
fails after the PREPARE step succeds, and then the client
disconnects, the transaction is automatically rolled back and can't
be recovered. I haven't figured out yet whether this is merely
dodgy, or an outright violation of the spec.
A
--
Andrew Sullivan | ajs@xxxxxxxxxxxxxxx
It is above all style through which power defers to reason.
--J. Robert Oppenheimer
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
