Re: PostgreSQL crashes with Qmail-SQL

Michael Devogelaere wrote:
> >
> >     4.  Instead  of investigating what the problem is, PostgreSQL
> >         was reported to *Crash*.
> Yes: it *crashed*. Since i disabled all debugging i cannot help you
> with investigating this problem. I hope i won't get the death penalty
> for this ;)
> >
> >     It cannot get any more obvious.
> Please elaborate.

    I  hope  you  don't take any of my comments personal. Because
    they are not! It is just that I am tired and bored  of  these
    every so often repeated MySQL optimized "benchmarks".

    I  see  a  clear difference between a database server process
    crash and a disabled service caused by  misbehaving  sysadmin
    scripts and/or bad service because of contra-optimized client
    behaviour.

    This is exactly the same style of reporting  crashes  or  bad
    performace,  the  MySQL  folks  have  practiced  for years. I
    remember creating  and  dropping  tables  a  couple  thousand
    times,  then VACUUM with a user that doesn't have permissions
    to vacuum system catalogs, and report bad performance because
    the  system  cache  got successfully screwed up ... there was
    even a comment in the  script  saying  "this  makes  Postgres
    slow"  ...  haha.   Other  reported  *crashes* have been core
    dumps of the test-scripts, because Postgres dealt with datums
    bigger than the perl-client was able to swallow ... well, the
    test driver just reported a crash, not exactly where and why,
    does  that  really  matter?  MySQL shows success and Postgres
    does not, that's what counts.

    The  lowest  level  still  accepted  Transaction   Processing
    Council Benchmark, TPC-C, can be implemented with a SUT using
    MySQL. Do it using LAMP, if you want to learn what a database
    crash is ;-)

    There is a good reason why TPC has abandoned the TPC-1, TPC-A
    and TPC-B benchmarks. They are "too  simple"  to  be  of  any
    meaning  for  benchmarking  purposes  these days. Yet all the
    stuff  this  huge  crowd  of  MySQL-Lemmings  is   constantly
    babbling  about is even more simple than that!  They all have
    their reasons, the TPC members (basically all  serious  RDBMS
    vendors) on one side as well as the MySQL folks on the other.

    As a matter of fact, the MySQL folks  are  alone  with  their
    point  of view that "beeing fastest on a single-table-select"
    is the most important  criteria  for  a  relational  database
    management  system.  And  as another matter of fact, Lemmings
    get what Lemmings deserve, MySQL!


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com