WAL and Re: MySQL's (false?) claims... (was: Re: PL/java?) - Mailing list pgsql-general

From Dr. Evil
Subject WAL and Re: MySQL's (false?) claims... (was: Re: PL/java?)
Date
Msg-id 20010826070834.16849.qmail@sidereal.kz
Whole thread Raw
In response to Re: MySQL's (false?) claims... (was: Re: PL/java?)  (David Ford <david@blue-labs.org>)
List pgsql-general
You guys shouldn't even be worrying about this.  Five years from now,
MySQL will be a much more mature product, but the way I see it now is
this:

MySQL: Great for message boards (Slashdot), information retrieval (an
on-line phone directory that's mostly static), or other lightweight
applications.

PG7.1: Great for doing more commercial type things: inventories,
accounting, and business in general, but it does lack some of the
high-end DB features, particularly replication and clustering, and
also some performance optimizations, which make it not quite in the
big-leagues yet.

Oracle: Great for everything beyond PG7.1.

MS-SQL: Use this one if you desperately need Western currency and want
to "lose" some plutonium!

PG7.2: It finally has replication!  This makes it a strong competitor
to Oracle for most applications.

Why is replication so important?  If the data you are dealing with are
valuable, you simply cannot trust them to one machine.  Machines catch
on fire, buildings burn down, earthquakes happen, lightning strikes.
A disaster can happen any time, anywhere.  The only solution to this
is replication.  Until PG has it, it can't be trusted with really
valuable data.

One thing which I would like to see in addition to replication is an
enhanced WAL mechanism.  Right now WAL only writes to a log file.
That's fine, but I can see two other things that WAL could do very
easily, which would be great for financial users, or others who deal
with valuable data: One is sending the tuple, as a string, off to
another server somewhere to be logged, perhaps in another DB of some
kind.  That way, when Server #1 gets struck by lightning, no problem,
not a single transaction has been lost.  This wouldn't take any major
mods to the WAL system; if someone would tell me where to look in the
code, I'll do it myself.  The second WAL change would be to allow WAL
to send output to a plain old dot matrix printer.  Yes, it's a
primitive thing to do, but again, if you are dealing with financial
transactions, sometimes it's a wonderful thing to be able to have them
in a human-readable read-only format.  No amount of elite hacking can
undo something which has been printed.  This technique, as primitive
as it sounds, is used all over the place.  Ever notice that when you
put your ATM card in the machine, you often hear a printer going?
Everything is logged the old-fashioned way.

Again, if someone will point me to the place in the WAL code where it
has the tuple and it wants to write it out, I'll make these mods
myself.

pgsql-general by date:

Previous
From: David Ford
Date:
Subject: Re: speed of communication and pgsql development
Next
From: Michael Meskes
Date:
Subject: Re: embedded SQL cursos declare fails