cbbrowne at ca.afilias.info wrote:
>>On February 10, 2005 05:24 am, Andreas Pflug wrote:
>>
>>>- sl_table and sl_sequence replication to client nodes is deferred until
>>>a subscription is started. IMHO both should be replicated immediately
>>>(just as sl_set), because their tab_id/seq_id must be unique across the
>>>cluster and in case of complicated scenarios it might well happen that a
>>>duplicate id is used which is not discovered until the subscription is
>>>started.
>>
>>Jan/Chris thought on this one ?
> 
> 
> It seems right to me for propagation of _identities_ of tables/sequences
> to occur immediately.

We're probably talking about the same thing: contents of sl_table and 
sl_sequence, not of the tables they're describing.

> 
> I would further "buy" that when doing "COPY_SET/ENABLE_SUBSCRIPTION", all
> of the objects should be checked and locked up front _before_ copying in
> data.  We have had cases where tables were cleaned out of place that
> should have been there, with the result that subscriptions got 3h in and
> THEN failed.
> 
> We have also had cases where COPY_SET failed because vacuum scripts were
> running and a "deadlock-capable" series of vacuums backed up alongside
> COPY_SET.  Locking _everything_ would make that either succeed very
> quickly or fail very quickly.
> 
> Mind you, it's not exactly a tiny change.

:-)

> 
> 
> I _disagree_ with this extension of sl_node; it wouldn't provide the
> benefit it is intended to.
> 
> What would make more sense would be to have a table that is an analogue to
> ADMIN CONNINFO...  Perhaps something like...
> 
> create table sl_conninfo (
>   co_id integer not null,
>   co_node integer not null,
>   co_conninfo text not null
> );
> create unique index slcinfo_pkey on sl_conninfo(co_id, co_node);
> 
> The value "co_id" indicates the ID of a "control node"; for each such
> node, you'd have a list of nodes and conninfo values.  If you're operating
> from "control node 1", then the way to access the nodes (e.g. - what you'd
> put at the top of a Slonik script) would be the co_conninfo values.

Actually, we already have this kind of structure: sl_node/sl_path.
We could simply use 1..n nodes, which are not participating in the 
replication traffic, but are just describing classes of admin clients. 
Each pgAdmin client then chooses to be like a certain node, and has its 
connection information.



> 
> And people, keep in mind that the cases where this distinction matters are
> the complex cases.
> 
> The _typical_ use of Slony-I probably involves having a couple of nodes
> with very clear singular network addresses.  Node 1 is "always" our_db1;
> node 2 is "always" our_db2, no matter where you are in the local network.
> 
> The scenarios where it's important to distinguish between sl_path values
> and what is in "admin conninfo" are the ones where you probably have some
> combination of:
> 
>   - Nodes at multiple physical sites
>   - Complex firewalls (perhaps multiple firewalls)
>   - Hosts that have multiple network addresses that _aren't_ accessible
>     everywhere
> 
> The simple answer may be for pgAdmin to ignore the distinction, for now,
> with the result that it only copes with simple network configurations. 
> But for "full generality," or "full power," it will be necessary to have
> some place in pgAdmin to record the paths from the admin workstation to
> all of the nodes.  Which suggests something like sl_conninfo.
> 
> The "cool extension" would be for sl_conninfo to contain configuration
> information to allow pgAdmin (or other tools) to construct connections,
> e.g. - establishing SSL tunnels to get at "particularly remote" locations.

Frankly, I regard ssl tunnel setup as vpn like stuff, leaving that to 
system admins. He might decide "server1 is accessible for my ssh-tunnel 
clients as localhost:5433, server2 as localhost:5434, while local 
clients will use server1:5432 and server2.5432", so that's what has to 
be the path information for that "ssh-tunnel client" and "local client" 
node.

Regards,
Andresa