Csaba Nagy nagy at ecircle-ag.com
Wed Jul 2 09:02:56 PDT 2008
On Wed, 2008-07-02 at 11:37 -0400, Andrew Sullivan wrote:
> If you can't schedule 10 minutes of downtime for a schema change, then
> Slony's the wrong tool for your job.  Sorry.  It can't provide five-nines.

I could live with that if I would be convinced that it is the case,
which I'm not... it must be a way to achieve a lower contention schema
update scenario which is generic enough.

> The script will get more testing for your environment if you write it for
> your environment.  A general-purpose script isn't ever going to get enough
> testing.  And you don't have to cross your fingers: those functions _get
> called all the time_.  They're what Slony uses. 

It's not about the reliability of the slony bare metal functions, it's
all about the reliability of _my_ judgment when applying them... all the
security is coming from experience, and I would like to avoid as much as
possible experimenting on production DBs. Learning on test DBs has only
limited value, in my experience there will always be a small but
significant detail which makes the test machine work and the production
one break.

> You really have two choices, but they're not the ones you listed:
> 
> 1.  Live with the Slony-provided limitation.

If it is a real limitation, I will have to live with it, but as I said
I'm not convinced. There must be a way to do it...

> 2.  Become expert in Slony, and then write something that reduces the locks
> taken while still behaving safely in your environment.
> 
> If you want all of fast, cheap, and good, you're not going to get it.  Sorry
> :-(

Well I want the best open source I can get. And I'm not shy of doing it
myself, it's just slony is an incredibly complicated beast, and I just
can't trust any home-grown solution enough to just use it and hope that
I didn't overlook anything... that's why I would hope a generic tool
which is reviewed by people who know why it is wrong if it is.

In this very moment I don't have the time to research this, but in the
long run I definitely will find the time to look at it as it is the most
problematic issue with slony for us. And there must be a way to fix
it...

Cheers,
Csaba.






More information about the Slony1-general mailing list