> 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.

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.

>> - It would be quite handy if sl_node would be extended by a column
>> no_conninfo which contains a connect string, effectively a path for
>> external tools (equivalent to ADMIN CONNINFO).
>
> The problem with this is that path may change depending on where you are
> admining from.

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.

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.