They're adding REPLICATION in 2010, not clustering ... Most replication systems 
are asynchronous and, as a result, don't guarantee transaction commitment to 
the replicants in the event of a failure, which means it's not really a 
suitable option for fail-over/ha, only for backups.  Bucardo is new, though. 
I'll have to try that one out.  Incidentally, the page on the pg site that 
lists the options for replication/clustering should have an extra column 
labeled "Piece of Shit" and they should all be "YES"'s. I managed to corrupt 
the cluster under pgpool and pgcluster in like 10 seconds.  Not to mention 
they're almost all implemented as hacky triggers.

ms

On Dec 3, 2009, at 6:29 PM, Miguel Arroz wrote:

> Hi!
> 
>> Q: Does PostgreSQL have replication?
>> A: Yes, currently we have a half-dozen different replication tools, 
>> depending on the user's purpose and platform. This is limited to 
>> master-slave replication in mature open source projects, including built-in 
>> PITR and Slony-I. Multi-master replication is available in the new project 
>> Bucardo as well as in various clustering tools. Built-in simple replication 
>> is planned for version 8.5, due in 2010.
> 
>   It didn't. Let's wait for 8.5! :)
> 
>   Yours
> 
> Miguel Arroz
> 
> On 2009/12/03, at 23:26, Miguel Arroz wrote:
> 
>> Hi!
>> 
>>  http://archives.postgresql.org/pgsql-hackers/2008-05/msg00913.php
>> 
>>  I don't know if it made into 8.4 or not, but they eventually understood 
>> they needed a better solution.
>> 
>>  Yours
>> 
>> Miguel Arroz
>> 
>> On 2009/12/03, at 23:20, Mike Schrag wrote:
>> 
>>> Also, full disclosure -- i DO use Postgresql and I think it's a great 
>>> database, but I always feel a little queasy when I do a deployment with PG 
>>> without clustering support. There's always the feeling of "i sure hope this 
>>> doesn't screw me." FrontBase has clustering, but has an obnoxious bug with 
>>> clustered sequences which basically requires that you use guid pks, which 
>>> none of our stuff does, so it's pretty likely MySQL is in my future.
>>> 
>>> ms
>>> 
>>> On Dec 3, 2009, at 6:18 PM, Mike Schrag wrote:
>>> 
>>>> Caveat here -- I don't use MySQL (yet) for anything real.  InnoDB is acid, 
>>>> though.  I agree that you should never run a myisam mysql for most normal 
>>>> systems and that it's strange that this is the default, but the fact is 
>>>> that you CAN set it to innodb, and it's a perfectly capable (if not VERY 
>>>> capable) database.
>>>> 
>>>> Soooooo -- I'm calling this out as FUD. Search google for "postgresql 
>>>> corruption" and you'll get plenty of matches, too:
>>>> Results 1 - 10 of about 164,000 for postgresql corruption.
>>>> Results 1 - 10 of about 12,700 for mysql innodb corruption.
>>>> 
>>>> There are quite a few huge systems that are running on MySQL. And the 
>>>> simple fact that you can cluster it actually makes it far more resilient 
>>>> than postgresql. Go try to setup a fault tolerant deployment of PG. Have 
>>>> fun and let me know when you're done.
>>>> 
>>>> ms
>>>> 
>>>> On Dec 3, 2009, at 6:10 PM, Miguel Arroz wrote:
>>>> 
>>>>> Hi!
>>>>> 
>>>>> There is nothing "specifically" wrong about using MySQL as a database for 
>>>>> WO. What's wrong is using MySQL at all! ;)
>>>>> 
>>>>> Essentially, it sucks. The first concern of MySQL authors is speed, and 
>>>>> only then correctioness. This may be seen my the existence of InnoDB 
>>>>> itself. First, speeeeeed. A few years later, yeah, this actually might be 
>>>>> usable in something else than a blog if we actually add ACID properties 
>>>>> to it!
>>>>> 
>>>>> In my Univ, the IT team who deals with the central systems moved 
>>>>> everything they could from mysql to PostgreSQL. Among other reasons, once 
>>>>> in a while a MySQL table corrupted itself. PostgreSQL is much more robust.
>>>>> 
>>>>> As always in software engineering, everything is a compromise. There may 
>>>>> be a few situations where MySQL is dramatically faster than PostgreSQL, 
>>>>> and the inverse is also true, it depends on the usage and the DB 
>>>>> architecture. This to say that you should use what better suits your 
>>>>> needs. But what I would not expect is MySQL to... you know... work! ;)
>>>>> 
>>>>> Yours
>>>>> 
>>>>> Miguel Arroz
>>>>> 
>>>>> On 2009/12/03, at 22:58, Kieran Kelleher wrote:
>>>>> 
>>>>>> Miguel, anyone, please enlighten me as to what specifically is wrong 
>>>>>> with using MySQL InnoDB as a database for WO because I have not seen any 
>>>>>> problem, but then I have not used PostgreSQL or FrontBase either - so 
>>>>>> maybe I don't see a problem that I should be concerned about.
>>>>>> 
>>>>>> -Kieran
>>>>>> 
>>>>>> On Dec 3, 2009, at 5:41 PM, Miguel Arroz wrote:
>>>>>> 
>>>>>>> Hi!
>>>>>>> 
>>>>>>> On 2009/12/03, at 22:32, Kieran Kelleher wrote:
>>>>>>> 
>>>>>>>>>> I create new OSCs for most background tasks. The one thing is that I 
>>>>>>>>>> dispose() on it at the end of the task .... and the dispose() is 
>>>>>>>>>> only useful if you use ERXJDBCAdaptor is used since the regular WO 
>>>>>>>>>> 5.3 jdbc adaptor opens two connections for every OSC and leaves the 
>>>>>>>>>> stupid things open forever. ERXJDBCAdaptor only opens one db 
>>>>>>>>>> connection and releases it when u call dispose() IIRC.
>>>>>>>>> 
>>>>>>>>> Dude! 
>>>>>>>>> <http://terminalapp.net/webobjects-postgresql-and-db-growing-and-growing/>
>>>>>>>>>  ;)
>>>>>>>> 
>>>>>>>> Dude!  www.mysql.com - innodb (or cluster NDB) .... doesn't "grow and 
>>>>>>>> grow"   (and it is not a "toy", no matter what Chuck says ;-)  )
>>>>>>> 
>>>>>>> No, it's a disaster! ;)
>>>>>>> 
>>>>>>> The "growing" is a side effect of leaving the transaction opening that 
>>>>>>> happens on PostgreSQL due to its architecture, but the point is the 
>>>>>>> same, do what I say there to avoid the dumb connection. :)
>>>>>>> 
>>>>>>> Yours
>>>>>>> 
>>>>>>> Miguel Arroz
>>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>> Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>> http://lists.apple.com/mailman/options/webobjects-dev/arroz%40guiamac.com
>>>>>> 
>>>>>> This email sent to ar...@guiamac.com
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Do not post admin requests to the list. They will be ignored.
>>>>> Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>> http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40mdimension.com
>>>>> 
>>>>> This email sent to msch...@mdimension.com
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Do not post admin requests to the list. They will be ignored.
>>>> Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
>>>> Help/Unsubscribe/Update your Subscription:
>>>> http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40mdimension.com
>>>> 
>>>> This email sent to msch...@mdimension.com
>>> 
>>> 
>> 
>> 
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/webobjects-dev/arroz%40guiamac.com
>> 
>> This email sent to ar...@guiamac.com
> 
> 

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to