Add an existing user table to a replication set. The set cannot currently be subscribed by any other node - that functionality is supported by the SLONIK MERGE SET(7) command.
ID of the set to which the table is to be added.
Origin node for the set. We might imagine a future version of slonik figuring out this information by itself, but there do lie race conditions, there.
Unique ID of the table. These ID's are not only used to uniquely identify the individual table within the replication system. The numeric value of this ID also determines the order in which the tables are locked in a SLONIK LOCK SET(7) command for example. So these numbers might represent any applicable table hierarchy to make sure the slonik command scripts do not deadlock at any critical moment.
This ID must be unique across all sets; you cannot have two tables in the same cluster with the same ID.
Note that Slony-I generates an in-memory array indicating all of the fully qualified table names; if you use large table ID numbers, the sparsely-utilized array can lead to substantial wastage of memory. Each potential table ID consumes a pointer to a char, commonly costing 4 bytes per table ID on 32 bit architectures, and 8 bytes per table ID on 64 bit architectures.
The full table name including the name of the schema.
A descriptive text added to the table entry.
SET ADD TABLE ( SET ID = 1, ORIGIN = 1, ID = 20, FULLY QUALIFIED NAME = 'public.tracker_ticket', COMMENT = 'Support ticket' );
Here are some of the error messages you may encounter if adding tables incorrectly:
Primary keys (or candidates thereof) are required to have all column defined as NOT NULL. If you have a PK candidate that has columns that are not thus restricted, Slony-I will reject the table with this message.
The table id, stored in
sl_table.tab_id, is required to be unique
across all tables/nodes/sets. Apparently you have tried to
reused a table ID.
This will normally occur with candidate primary keys; apparently the index specified is not available on this node.
Worse than an index missing, the whole table is missing. Apparently whatever process you were using to get the schema into place everywhere didn't work properly.
You can only replicate (at least, using SET ADD TABLE) objects that are ordinary tables. That doesn't include views or indexes. (Indexes can come along for the ride, but you don't ask to replicate an index...)
You need to define a replication set before assigning tables to it.
This will occur if set 4 is configured with, as origin, node 1, and then you submit a SET ADD TABLE request involving that set to some other node than node 1. This would be expected to occur if there was some confusion in the admin conninfo configuration in the slonik script preamble...
Slony-I does not support adding tables to sets that are already participating in subscriptions. Instead, you need to define a new replication set, and add any new tables to that set. You might then use SLONIK MERGE SET(7) to merge the new set into an existing one, if that seems appropriate.
On the origin node, this operation requires a brief exclusive lock on the table in order to alter it to add replication triggers. On subscriber nodes, corresponding locking takes place at the time of the SUBSCRIBE_SET event.