Re: Slony-I makes progress

Поиск
Список
Период
Сортировка
От Alex J. Avriette
Тема Re: Slony-I makes progress
Дата
Msg-id 20040305134931.GS1096@posixnap.net
обсуждение исходный текст
Ответ на Re: Slony-I makes progress  (Jochem van Dieten <jochemd@oli.tudelft.nl>)
Ответы Re: Slony-I makes progress  (Jan Wieck <JanWieck@Yahoo.com>)
Список 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@posixnap.net
Alex J. Avriette, Unix Systems Gladiator
"v shpxvat ungr jvaqbjf naq v ubcr ovyy tngrf oheaf va uryy." - Ronald O. Thompson, "13"


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Rudolpho Gian-Franco Gugliotta
Дата:
Сообщение: Postgresql JDBC-Driver
Следующее
От: Tom Lane
Дата:
Сообщение: Re: A plan to improve error messages with context, hint and details.