On Thu, Jul 28, 2016 at 8:09 PM, Edson Richter <edsonrich...@hotmail.com> wrote:
> Em 28/07/2016 13:07, Chris Travers escreveu: > > > > On Thu, Jul 28, 2016 at 3:38 PM, Scott Marlowe <scott.marl...@gmail.com> > wrote: > >> On Wed, Jul 27, 2016 at 9:51 AM, Geoff Winkless <pgsqlad...@geoff.dj> >> wrote: >> > On 27 July 2016 at 15:22, Scott Mead <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. > Both have potential for the same sorts of problems to be sure, but the difference is that process isolation does give you some protection and helps contain the issues. Not the only way to do so, to be sure. But getting some extra help from the OS and CPU in this area really is not a bad thing. My point is that I like the design decision here regarding 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). > MySQL is a good system for a few sorts of problems. InnoDB is well-optimized for simple primary key lookups. So if really what you want is a SQL access to a dumb information store with network access and reasonable write scalability, it is not a bad system. You will note that is actually pretty close to Uber's use case with schemaless. But at that point, foreign keys are pretty close to being optional..... > > > Regards, > > Edson Richter > > -- Best Wishes, Chris Travers Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in. http://www.efficito.com/learn_more
