Re: Uber migrated from Postgres to MySQL

On 28/07/2016 21:09, Edson Richter wrote:
> Em 28/07/2016 13:07, Chris Travers escreveu:
>>
>>
>> On Thu, Jul 28, 2016 at 3:38 PM, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com <mailto:scott(dot)marlowe(at)gmail(dot)com>> wrote:
>>
>> On Wed, Jul 27, 2016 at 9:51 AM, Geoff Winkless <pgsqladmin(at)geoff(dot)dj <mailto:pgsqladmin(at)geoff(dot)dj>> wrote:
>> > On 27 July 2016 at 15:22, Scott Mead <scottm(at)openscg(dot)com <mailto:scottm(at)openscg(dot)com>> wrote:
>> >>
>> >> "The bug we ran into only affected certain releases of Postgres 9.2 and
>> >> has been fixed for a long time now. However, we still find it worrisome that
>> >> this class of bug can happen at all. A new version of Postgres could be
>> >> released at any time that has a bug of this nature, and because of the way
>> >> replication works, this issue has the potential to spread into all of the
>> >> databases in a replication hierarchy."
>> >>
>> >>
>> >> ISTM that they needed a tire swing and were using a dump truck. Hopefully
>> >> they vectored somewhere in the middle and got themselves a nice sandbox.
>> >
>> >
>> > At least his bug got fixed. The last 2 bugs I reported to MySQL resulted in
>> > an initial refusal to accept any problem existed, followed by (once that
>> > particular strategy had run out of steam) the developer simply ignoring the
>> > bug until it was closed automatically by their bug system. As far as I'm
>> > aware those bugs still exist in the most recent version.
>>
>> Best / worst MySQL bug was one introduced and fixed twice. Someone put
>> in a short cut that sped up order by by quite a bit. It also meant
>> that order by desc would actually get order by asc output. It was
>> inserted into the code due to poor oversite / code review practices,
>> then fixed about 9 months later, then introduced again, and again,
>> took about a year to fix.
>>
>> The fact that it was introduced into a General Release mid stream with
>> no testing or real reviews speaks volumes about MySQL and its
>> developers. The fact that it took months to years to fix each time
>> does as well.
>>
>>
>>
>> As for MySQL issues, personally I love the fact that a single query inserting a bunch of rows can sometimes deadlock against itself. And I love the fact that this is obliquely documented as
>> expected behavior. May I mention I am *really glad* PostgreSQL doesn't go the whole multi-threaded backend route and that this is exhibit A as to why (I am sure it is a thread race issue between
>> index and table updates)?
>
> Sorry, I think this is a biased vision. Multi-threading will show as much problems as multi-process - both has to have simultaneous access (or, at least, right semaphor implementation to serialize
> writes and syncronize reads).
> The fact is **on this point at least** is that Postgres is correctly implemented, and MySQL is faulty.
> I've faced the "lost FK integrity hell" (caused by the problem above) with MySQL long before decided to migrate all systems to PostgreSQL.
> My personal experience is that MySQL is excellent for data that is not sensitive (web site, e-mail settings, etc). Everything else goes to PostgreSQL (or Oracle, or MS SQL Server, or Sybase, or DB2
> - in *my* order of preference).
>

+1

>
> Regards,
>
> Edson Richter
>

--
Achilleas Mantzios
IT DEV Lead
IT DEPT
Dynacom Tankers Mgmt