Re: Justifying a PG over MySQL approach to a project - Mailing list pgsql-general

From Steve Atkins
Subject Re: Justifying a PG over MySQL approach to a project
Date
Msg-id F5808377-F27A-4C3B-93C2-47208D1DF95C@blighty.com
Whole thread Raw
In response to Re: Justifying a PG over MySQL approach to a project  (Scott Marlowe <scott.marlowe@gmail.com>)
Responses Re: Justifying a PG over MySQL approach to a project  (Peter Geoghegan <peter.geoghegan86@gmail.com>)
List pgsql-general
On Dec 16, 2009, at 3:05 PM, Scott Marlowe wrote:

> On Wed, Dec 16, 2009 at 2:44 PM, Greg Smith <greg@2ndquadrant.com> wrote:
>> You've probably already found
>> http://wiki.postgresql.org/wiki/Why_PostgreSQL_Instead_of_MySQL:_Comparing_Reliability_and_Speed_in_2007
>> which was my long treatment of this topic (and overdue for an update).
>>
>> The main thing I intended to put into such an update when I get to it is
>> talking about the really deplorable bug handling situation for MySQL, which
>> is part of how all the data corruption issues show up.  There's a good
>> overview of its general weirdness at
>> http://www.xaprb.com/blog/2007/08/12/what-would-make-me-buy-mysql-enterprise/
>> and the following series of pages lead you through my favorite set of bugs:
>>
>> http://www.mysqlperformanceblog.com/2007/10/04/mysql-quality-of-old-and-new-features/
>> http://bugs.mysql.com/bug.php?id=28591
>> http://bugs.mysql.com/bug.php?id=31001
>> http://bugs.mysql.com/bug.php?id=37830
>>
>> Basically, they made a performance optimization *in the stable release* and
>> fundamentally broke very basic behavior which didn't get caught by their
>> internal QA at all.  That's a disaster that opens up serious questions about
>> both their project planning/structure and their QA too, far as I'm
>> concerned.
>
> The important point here is that the bug was introduced to a stable
> branch, fixed halfway, then detected again, then fixed yet again.
> This does not instil confidence in their QA or code review.
>
> As a for instance of who runs PostgreSQL and who runs MySQL, we have
> slashdot and the .info and .org TLDs.  When you go to slashdot.org and
> it's not working right, that's MySQL acting up.  When you can't get to
> any .info or .org domains, that's PostgreSQL.

My information is quite dated, but as I understand it that's not actually
true.

Postgresql is used for domain registration management at those domains
(amongst others). It's not used for anything related to resolution of those
domains in real time that I'm aware of. If you were unable to register
or transfer a .org domain that would be a postgresql failure.

>
> I've had slashdot have a non-functioning database underneath it quite
> a few times (note that the site stays up, but you can't edit anything
> because it's all static).  I've never once had the .org or .info TLDs
> go down on me.

Lets not draw too much attention to the database that's responsible
for that stability. :)

Cheers,
  Steve


pgsql-general by date:

Previous
From: Scott Marlowe
Date:
Subject: Re: Justifying a PG over MySQL approach to a project
Next
From: Andrew Lazarus
Date:
Subject: A kludge for updateable views and Hibernate