Re: Slony-I makes progress

From: "Alex J(dot) Avriette" <alex(at)posixnap(dot)net>
To: Jochem van Dieten <jochemd(at)oli(dot)tudelft(dot)nl>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Slony-I makes progress
Date: 2004-03-05 13:49:31
Message-ID: 20040305134931.GS1096@posixnap.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers pgsql-hackers

On Fri, Mar 05, 2004 at 12:47:23AM +0100, Jochem van Dieten wrote:

> >I personally don't think that a GUI tool should be the province of the
> >Slony project. Seriously. I think that Slony should focus on a

I very much agree with this, but this is Jan's baby, so I didn't say
anything. I have personally never used a GUI with a postgres database
(well, okay, I used one for a bit to troubleshoot a problem my boss
was having with a pg node once), and I don't really plan to. I guess
I was unaware this is a common usage pattern.

> >command-line api and catalogs, and allow the existing GUI projects to
> >build a slony-supporting interface.
>
> Why a command line api? I believe it would make sense to be able
> to configure and control all nodes of the entire system from psql
> connected to any of the nodes. That would also facilitate the
> existing GUI projects in adding a Slony-manager.

In theory, most of the stuff that Slony is doing is within the
database, and as such, could be configurable via stored procedures. I
see a few problems with this.

First off, it is not possible to configure external applications (such
as erserver has a daemon) from within the database except through the
modification of tables within the database which are monitored by said
application.

Second, it increases the footprint of Slony on the database. I am
fairly uneasy about adding more tables, functions, and triggers to my
(already quite taxed) production database. To add further functions for
configuration, as well as related tables and triggers, makes my job
managing the database more difficult. Additionally, those commands are
queries. For something as trivial as configuration data, I would much
rather not be issuing queries against an already very busy database. I
am much more comfortable with the principle of external configuration
files and programs.

Lastly, and I may be the black sheep here, I don't find sql to be
particularly useful for doing things that require a complex grammar. In
this instance, I don't want to have to do something like:

production=# select slony_config_setval( 'log_dir', '/data/slony_logs');

to manage the configuration. Obviously, this could be worse than the
above example.

I don't understand the opposition to an external set of tools (even a
gui if need be). It seems to me, that until the postmaster has some
kind of native replication, all replication efforts will be based on
external programs. As such, they should be configured externally, and
be treated as any other daemon would be.

Alex

--
alex(at)posixnap(dot)net
Alex J. Avriette, Unix Systems Gladiator
"v shpxvat ungr jvaqbjf naq v ubcr ovyy tngrf oheaf va uryy." - Ronald O. Thompson, "13"

In response to

Responses

Browse pgadmin-hackers by date

  From Date Subject
Next Message Chris Gamache 2004-03-05 14:40:14 Security Wizard in III
Previous Message Christopher Browne 2004-03-05 03:18:36 Re: Slony-I makes progress

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2004-03-05 14:10:56 Re: [HACKERS] Another crack at doing a Win32 build under MINGW
Previous Message Rudolpho Gian-Franco Gugliotta 2004-03-05 13:25:32 Postgresql JDBC-Driver