Re: Justifying a PG over MySQL approach to a project

Поиск
Список
Период
Сортировка
От Steve Atkins
Тема Re: Justifying a PG over MySQL approach to a project
Дата
Msg-id F5808377-F27A-4C3B-93C2-47208D1DF95C@blighty.com
обсуждение исходный текст
Ответ на Re: Justifying a PG over MySQL approach to a project  (Scott Marlowe <scott.marlowe@gmail.com>)
Ответы Re: Justifying a PG over MySQL approach to a project  (Peter Geoghegan <peter.geoghegan86@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Scott Marlowe
Дата:
Сообщение: Re: Justifying a PG over MySQL approach to a project
Следующее
От: Andrew Lazarus
Дата:
Сообщение: A kludge for updateable views and Hibernate