Re: [GENERAL] Re: Is PostgreSQL ready for mission critical applications?

On Sun, 21 Nov 1999, Kane Tao wrote:

> I second this.  I am sure you will not be able to get a good idea of the
> database for some people have no problems with it and some do.  My main
> concern for the database used in a mission critical application is that
> 1)  It requires a VERY skilled DBA in both Unix and PostgreSQL

why?  compared to what I've seen of Oracle, PostgreSQL is pretty
brain-dead to operate...

> 2)  There are few tools that make for ease of development and
>     administration.

    can't really comment here as I do everything in perl *shrug*

> 3)  Documentation is no where near as detailed or all encompassing as a
>     database like Oracle.

    again, can't comment here as I've always found what I was looking
for...specific examples?

> 4)  There are certain instances when the database requires a rebuild from
>     scratch or tape that are not related to hardware failure or disk
>     corruption.

    version of PostgreSQL?

    my email system database was created on July 9th of this year, and
I've never had to reload it from tape or otherwise, and its used by
sendmail 24/7 for email delivery.  (v6.5.0)

    my account system database was created on March 3th of this year,
and has been running without a reboot/restart since June 7th, which was
the last reboot of that machine...never reloaded that system either, and
its an older 6.4.0 system.

> 5)  There are no transaction logs or redo logs that allow you to recover
>     the database to a point in time or handle hot online backups.

    being worked on...but you are right, not currently available.

> 6)  It does not scale up to multi processor/multi threading very well (As I
>     understand it).

    actually, postgresql would run better on a multi-cpu FreeBSD
machine then MySQL would, to be honest.  FreeBSD's SMP doesn't have the
ability to 'change cpu on a thread-by-thread basis', so the fact that
MySQL uses threads would actually be a drawback vs advantage (all threads
of the started processes would be stuck on the same CPU, even if the other
CPU was idle)...PostgreSQL, each forked instance would go to the more idle
CPU, since its a new process...

> 7)  A vacuum has to be run often (at a regular interval) taking up
>     valuable system resources...locking tables and sometimes just
>     failing utterly.

    why does it have to be run often?  it depends on you
application/database.  if you are changing your database around *alot*
(alot of update/deletes), yes, since you have to force it to do its own
garbage collection...the next release will remove the table locking
required, since Vadim's MVCC implementation removes the requirement for it
to do so.  I do not beleive that this is something that is in v6.5.3, but
believe its already in there for v7...don't quote me on that, I've been
wrong before...

    essentially, one of the ideas that's been toyed with (but I'm not
sure if anyone has worked on) is the concept of getting rid of the
requiremetn for a vacuum altogether.  with the new MVCC code, the concept
of a table lock has essentially been removed, so a 'vacuum' *could* be
done periodically by the system itself...sort of like the auto-disk
defragmentation code that is in alot of the Unix file systems ...

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org