On Jul 22, 2004, at 9:34 AM, Christopher Browne wrote:

>> So this doesn't fully answer my question about the status of
>> slonik. Has the concept of a set of Perl scripts met with wider
>> developer and community approval? Does it make the most sense for
>> propagation of Slony in terms of it becoming the generally accepted
>> (or one of the generally accepted) replication solutions for
>> postgres?  I'm not trying to be antagonistic; I'm just trying to
>> understand the development process and rationale and play a bit of
>> devil's advocate.
>
> My intent is to throw another choice up against the wall, so we can
> see what's going to stick better.

Sure. Makes sense. I guess I'm just curious as to how the development 
process around slony is going to congeal.

>> For instance, why not create slonik commands like
>>
>> SET ADD UNIQUELY CONSTRAINED TABLES
>> SET ADD UNCONSTRAINED TABLES
>> SET ADD ALL TABLES
>> SET ADD ALL SEQUENCES
>
> Because there may be some table that SHOULDN'T be replicated.
>
> In our applications, for instance, there are all the tables that are
> "officially" part of the server application, and then there are some
> utility tables that the DBAs periodically create when looking to
> repair some problem that has occurred.
>
> If we said "replicate all tables," that would include cruddy ones that
> perhaps should be thrown away.

Sure, but shouldn't that be up to the DBA to decide? I mean, including 
a DELETE command in SQL sure allows you to do destructive things to 
your data. Adding all tables

> A better approach would be to request all tables in a particular
> namespace, as it is somewhat more likely that a namespace will be kept
> clean.

I like this idea.

>>> Stick those three things in a config file, and it's dead easy to
>>> generate a suitable "create set" that first adds PK candidates and
>>> then builds the set of all the tables.

I forgot to ask this question earlier: Do you have an example of this 
"dead easy" process? I'm currently writing a meta-slonik utility for 
generation of my three lists (constrained tables, unconstrained tables, 
and sequences), but there's no point in reinventing the wheel if 
someone has already done this work.

>> Again, my point would be why not (plan to) have slonik handle this
>> work for you?
>
> Because it may take human planning to get this to all take place at an
> appropriate time.

I feel like the convenience would make up for it. I mean, I'm having to 
do a lot of human planning right now to work around the lack of 
automatic table specification procedures.

> For instance, suppose the database is rather large, and you have to
> very carefully schedule when the "unique key" creation will take place
> on some critical table, because that will lead to an application
> outage.  In that case, having slonik "magically handle this" would be
> downright undesirable.

Well, that's why I mentioned having the ability to add tables according 
to whether or not they're constrained or not.

>> I mean, what's the difference between a slonik command that grabs
>> all user relations and postgres itself in general. If a DBA trusts
>> the DBMS, then the DBA ought to be able to have some trust in the
>> extended development community that organizes around the DBMS.
>
> That only works if we're looking at:
>  - Development in the small, where everyone knows everyone, and
>  - Development under a tightly controlled set of DB management
>    doctrines.

So is the doctrine that differentiates PostgreSQL the fact that it's an 
implementation of SQL, which is an accepted standard?

> If there's any reason to need to be _careful_ about what data gets
> replicated, then magick becomes a major misfeature.

Yeah, I guess the entire process is dependent on the trust of the user 
community. I tend not to be too suspicious of magick when I trust a 
development community and have been actively following the development 
process. I know that not everyone in the postgres/slony user community 
fits that category, though.

To me the question boils down to simplicity/convenience vs. trust (in 
both the software and my abilities as a DBA type). I have the trust, 
but the features that would give me the simplicity/convenience I'd like 
to have aren't there, yet.

I think that eventually slony is going to need to include some 
semi-automated way of helping the user select the relations to be 
replicated. It sounds like the consensus is developing around a broad 
set of user tools, some of which might end up perl-based, some of which 
might end up web-based, and some of which might end up GUI-based. 
Optimally, there would be some logical way in which each of these 
solutions fit the general development structure and strategy of slony, 
and that a robust, cohesive feature set is available to all approaches 
(which I still think should include some combination of slonik and/or 
slony configuration files).

-tfo