Alex J. Avriette wrote:
On Wed, Mar 03, 2004 at 04:57:28PM -0500, Jan Wieck wrote:After some substantial progress on the Slony-I engine development, I'd like to give a little status report and invite everyone who wants to participate in this project to join the mailing list and the development team.
Jan, thank you so much for your hard work on this project.
Both, the provider change and the failover need a much more complex configuration than the current shell scripts can setup. The problem is that the configuration and administration tools are not designed yet. So here is a huge field for others to step up and take a key role in this project.
So what are you looking for here? When I last built slony, things mostly worked, but a few niggling details were broken. I was going to submit a few patches, but when I talked to you, it seemed like you weren't quite ready for patches. Is the tree stable enough that I could do some work on it and expect it to remain relatively consistent over a few hours or even a day or two?
What I am looking for is a super-comfortable GUI application that makes planning and configuring a master-cascaded-multislave replication system doable by everyone who can identify a clickable button.
Honestly, I personally can live with a sh+sed+m4 tool collection. But I guess only few would agree to that. So it's basically up to you and everyone else around here what the outcome of this is.
What is required to fit into the data-center is a batch utility that can be called in a script and that causes a currently failing cluster to change the configuration (change the origin of data sets, change providers, drop nodes ... that kind of stuff). The same utility would ideally be able to setup new nodes etc. so that it can be used as an interims solution until the GUI wizzard is ready for prime time.
The current CVS replicates fine and the test_?_pgbench scripts in the src/ducttape directory do it all at once. I have changed a couple of things in the autoconf stuff. The whole thing is now expected to be compiled and installed by the postgres user with --prefix pointing to the postgres home directory (the same as the --prefix for the PG installation from sources was). The problem here is, that if we ever want to create a single C function from a GUI tool on a remote box, its shared library better be in the PostgreSQL lib directory so it can be ... AS '$libdir/objfile' no matter where that is and what extension shared objects on that architecture have.
Also, to get this out of the way (as it presently plagues erserver), do you have a particular language in mind? I'd like to avoid the dogmatic jihad by not submitting a perl tool if the eventual goal is to be end-to-end C (or java or tcl or whatever).
For the production batch commandline utility I think it is C.
Other than that ... I said the field is open.
Jan
-- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
