Christopher Browne cbbrowne at ca.afilias.info
Thu Mar 6 10:51:38 PST 2008
"lio bod" <liobod.slony at gmail.com> writes:
> Thx for the fix.

> I havn't test the last HEAD release yet. I 'm afraid i won' t have any time for this by now.
>
> The generated *.slonik files helps me as sample that i modify with my little hands...
>
>  
>
> Btw, the store_paths.slonik file looks weird :
>
>  
>
> STORE PATH (SERVER=1, CLIENT=2, CONNINFO='dbname=mydb host=myhost1 user=pgslony port=5432'); else
> STORE PATH (SERVER=1, CLIENT=2, CONNINFO='dbname=mydb host=myhost2 user=pgslony port=5432');
> STORE PATH (SERVER=2, CLIENT=1, CONNINFO='dbname=mydb host=myhost2 user=pgslony port=5432'); else
> STORE PATH (SERVER=2, CLIENT=1, CONNINFO='dbname=mydb host=myhost2 user=pgslony port=5432');
>
>  
>
> and i'm not really estonished by error produced :
>
>  
>
> $> slonik store_paths.slonik
> store_paths.slonik:2: ERROR: syntax error at or near else
>
> another bug or wrong use?

Hmm.  That's the same sort of bug that you pointed out before, in
another spot.  I'm not sure how that broke in version 1.2.
Conceivably a cut'n'paste problem?

> I go on on with with some idea of improvement even if i guess they
> are so obvious that they might already be in your roadmap :
>
> - why not separate files among thiner functionnality : 1 file
> *.slonik file for creating cluster, another for nodes, another for
> set, another for tables, another for sequences , ..., what else?,
> and subscription

The purpose of the script was to configure replication fairly simply.
I'm not sure I want to add every conceivable bit of extra
functionality.

> - why not produces undo *.slonik files (with same granularity) :
> remove subscription, ..., untill remove cluster (even i still not
> sure of my self how to make so with bare metal).

Why not?  Because that doesn't fit with the name:
configure_replication.sh.

I don't want to complicate it for the sake of complicating it.

We already have the whole set of "altperl" scripts that have grown
challenging to support because:

 1.  A lot of the "mature users" find it simpler to go straight to
     writing slonik scripts.

 2.  The "altperl" scripts have grown to require a pretty
     sophisticated set of Perl data structures to describe clusters, 
     which require that the users do some sophisticated reading,
     and nonetheless, the scripts make a whole lot of simplifying
     assumptions about the "shape" of the cluster, and therefore
     aren't anywhere near "fully general" in being able to express
     all the sorts of things that someone might want to do to a
     cluster.

     (Notably: if you have a pretty complex network structure, Slony-I
     can cope with this, but "altperl" has no way to represent that.)

I'm not sure what to do with/about the "altperl" tools...  They get
just enough "patch" attention from users that it would seem unjust to
deprecate them, but they aren't being really properly maintained, all
the same.  I decline to be the "proper maintainer;" if there isn't
enough community interest, I think they *should* get deprecated.

I think I'd prefer to keep "configure_replication.sh" on the simple
side, so that it's clear that it's a "crutch" to help, as opposed to
trying to make it the "comprehensive solution" that it really can't
be.
-- 
(format nil "~S@~S" "cbbrowne" "cbbrowne.com")
http://linuxdatabases.info/info/linux.html
WARNING - the content of this message may be erroneous, misspelled and
perhaps even flammable.  It also contains small parts that could cause
asphyxiation.  NOT RECOMMENDED FOR CHILDREN UNDER 3 YEARS OF AGE


More information about the Slony1-general mailing list