X-Original-To: pgsql-general-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 1483ED904F for ; Fri, 16 Sep 2005 16:40:37 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 51031-04 for ; Fri, 16 Sep 2005 19:40:31 +0000 (GMT) Received: from koolancexeon.g2switchworks.com (mail.g2switchworks.com [63.87.162.25]) by svr1.postgresql.org (Postfix) with ESMTP id 0CB3DD6E22 for ; Fri, 16 Sep 2005 16:40:30 -0300 (ADT) Received: mail.g2switchworks.com 10.10.1.8 from 10.10.1.37 10.10.1.37 via HTTP with MS-WebStorage 6.5.6944 Received: from state.g2switchworks.com by mail.g2switchworks.com; 16 Sep 2005 14:40:32 -0500 Subject: Re: Replication From: Scott Marlowe To: Russ Brown Cc: pgsql-general@postgresql.org In-Reply-To: <432B0627.2030700@gmail.com> References: <432B0627.2030700@gmail.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1126899631.30120.43.camel@state.g2switchworks.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 16 Sep 2005 14:40:32 -0500 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.005 required=5 tests=[AWL=0.005] X-Spam-Level: X-Archive-Number: 200509/671 X-Sequence-Number: 83686 On Fri, 2005-09-16 at 12:51, Russ Brown wrote: > Scott Ribe wrote: > >>How about a third choice: you can also use a proven, reliable and tested > >> replication solution that is included in the core system because the > >>core system basiclly provides it anyway. > > > > > > Sure, but that one is spelled "Sybase", not "MySQL" ;-) > > > > > > It's amazing how misunderstood my post was. > > My third choice was a hypothetical future version of PostgreSQL, > modified from its current form very slightly to include a form of > replication 'out of the box': a couple of scripts to enable WAL log > transfer and also a solution to the problem of WAL log delay mentioned > by other posters. > > I only mentioned MySQL because their 'out of the box' solution involves > transferring the binlogs, which is similar to the method of transferring > the PostgreSQL WAL logs, and it just made me think. That's all. I wasn't > comparing, I wasn't suggesting MySQL is better than PostgreSQL. I wasn't > suggesting that they have the 'ultimate' solution. I wasn't even > suggesting that they have a good solution. It just made me think. That's > all. > > Well, I've learned my lesson. Next time I post I'll be sure not to > mention MySQL in any way, shape or form. Actually, I would just suggest to not hold it up as an example of how things should be done. That would work for me. There was a time, 5 to 10 years ago, when MySQL AB spent a LOT of energy demonizing PostgreSQL to make themselves look better. There were pages of misinformation in their documentation about how PostgreSQL was basically crap, and MySQL did everything right, and a lot of people spent a lot of time debunking that. MySQL AB now plays better with others, and hasn't engaged in the kind of character assassination they once did, but there's STILL a sore spot for most PostgreSQL users and developers there, because they used to have to spend a lot of energy and time explaining that what was on the MySQL site was lies and misinformation. A LOT of time. And it did hurt PostgreSQL, in terms of keeping people away from it. So, there's an almost automatic response triggered by someone mentioning how MySQL does things, especially if they're perceived to be holding MySQL up as an example to the PostgreSQL community on how things should be done. In my original post, my main point wasn't just against MySQL, it was against the philosophy that just because replication is included and part of the core of a database, it doesn't mean that it's reliable or well tested. And MySQL is a fine example of that. Their replication really does have a lot of issues. So, feel free to mention MySQL, but know that mostly when it's mentioned here, it's mentioned as an example of how things shouldn't be done. In terms of coding, marketing, testing, or licensing.