> => In MySQL you have to repair your tables manually if corruption occurs.
> PostgreSQL is coded so that corruption cannot occur.

Unless you're running pre-7.1, in which doing any of the following
may corrupt an entire database so badly that pg_dumpall crashes on it.

 * Table A.  Create mirror table B.  Insert into B.  Drop A.  Rename B
   to A.  Watch backend crash randomly, corrupting said table to
   unrecognizable form - hence corrupting entire database.  This may only
   happen once every 1000 times the process is repeated, but *will*
   occur eventually.  This happened more in 6.5.
 * Select, insert, update, whatever.  Eventually, postgrees will
   report that the back end has "exited unexpectedly."  This is
   easier to repeat on an installation serving many simultaneous
   connections, especially if any database has been affected by:
 * Inserting any row with a total column length of 8k or higher, minus
   row/column overhead.  For even more fun, insert a row of arbitrary
   length, or use multiple text columns.
 * Selecting, updating, or even remotely touching any table which has
   an example of the above.  Yes, this means that you can't even
   delete the offending row, or pg_dump the database to remove it
   manually.

What about pg_dump, you say?  Sure, that'll work.  Get the tables that
aren't corrupted, like you know which ones they are.  Then all you have
to do is not give a rat's ass about the data in the table that *is*
corrupted.  Sounds easy, right?

All of this vanished like smoke when 7.1 came out.  In my opinion, 7.1 is
the first real release of postgres, and hence Mysql is fully justified in
most of its accusations/comparisons.  Until 7.1, postgres didn't have a
snowball's chance in hell at beating mysql on the stability front, now the
odds are a little more even.

Either way, don't dare sit there and tell me postgres doesn't corrupt
tables.  I would actually prefer a utility to integrity check/repair a
corrupted table into something that the database could read, rather than
give the data up for a loss and run for our backups, as we have been doing.

-- 
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
| Shaun M. Thomas                INN Database Programmer              |
| Phone: (309) 743-0812          Fax  : (309) 743-0830                |
| Email: [EMAIL PROTECTED]    AIM  : trifthen                      |
| Web  : hamster.lee.net                                              |
|                                                                     |
|     "Most of our lives are about proving something, either to       |
|      ourselves or to someone else."                                 |
|                                           -- Anonymous              |
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+



---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Reply via email to