Re: [Wonder-disc] [Wonder-cvs] SF.net SVN: wonder:[9002] trunk/Wonder/Applications/JavaMonitor/Sources/com /webobjects/monitor/application

[Mike S. <ms...@md...>]

> Yeah uh, thanks, but I don't need sharing of pain :)
>
> I need a solution for this problem, which either means a special
> PGSlony plugin that handles this crap. This should of course be
> solvable, but from what I understand, you need to distinguish between
> CREATE, ALTER and plain SQL when doing schema bumps. There are means
> to exec simple ALTER's in the cluster, but create or drop table need
> to be propagated into slony directly so the replication tables are set
> up.
Yeah, slony works with triggers, and there is no trigger for several  
of the DDL statements, which means there's nothing they can replicate  
off of.  It's a pretty nasty problem, and I suspect very hard to fix  
without actually modding PG.  Every replication and clustering  
solution for PG sucks, and it's really disappointing given that PG has  
checkboxes in almost every other comparison column.  Slony also isn't  
a sequential replicator, so it doesn't guarantee two-phase commit  
across the replicants, which means you can't even REALLY trust it for  
failover ... it probably works ... but maybe not.... From what I can  
tell at the moment, RHEL actually clusters the FILESYSTEM under PG,  
and does a failover of PG itself, which is sort of interesting (but  
doesn't address all the use cases of a real cluster, which is that you  
can do it without any downtime).  I wish I had more for you here ...  
It makes me a sad panda every time I go looking for info about this.   
Apparently there is a JDBC driver implementation that does two-phase- 
commit clustering at the JDBC level, which might be interesting to try  
(on my infinite to-do list) -- http://c-jdbc.objectweb.org/ .

ms