Em 28/07/2016 13:07, Chris Travers escreveu:
On Thu, Jul 28, 2016 at 3:38 PM, Scott Marlowe <scott.marl...@gmail.com <mailto:scott.marl...@gmail.com>> wrote:On Wed, Jul 27, 2016 at 9:51 AM, Geoff Winkless <pgsqlad...@geoff.dj <mailto:pgsqlad...@geoff.dj>> wrote: > On 27 July 2016 at 15:22, Scott Mead <sco...@openscg.com <mailto:sco...@openscg.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).
Regards, Edson Richter
