NAME

SET ADD TABLE - Add a table to a Slony-I replication set

SYNOPSIS

SET ADD TABLE (options);

DESCRIPTION

Add an existing usep table to a replication set. The set cannot cur‐
rently be subscribed by any other node - that functionality is support‐
ed by the MERGE SET(7) command.
SET ID = ival
ID of the set to which the table is to be added.
ORIGIN = ival
Origin node for the set. A future version of slonik might figure
out this information by itself.
ID = ival
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 LOCK SET(7) command for example. So these
numbers should 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 ta‐
bles in the same cluster with the same ID.
FULLY QUALIFIED NAME = ’string’
The full table name as described in TABLE ADD KEY(7).
KEY = { ’string’ | SERIAL }
(Optional) The index name that covers the unique and not null
set of columns to be used as the row identifier for replication
purposes. Or the keyword SERIAL to use the special column added
with a previous TABLE ADD KEY(7) command. Default is to use the
table’s primary key. The index name is not fully qualified; you
must omit the namespace.
COMMENT = ’string’
A descriptive text added to the table entry.
This uses “schemadocsetaddtable( integer, integer, text, name, text )”
[not available as a man page].

EXAMPLE

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:
Slony-I: setAddTable_int: table public.my_table PK column id nullable
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.
Slony-I: setAddTable_int: table id 14 has already been assigned!
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.
Slony-I: setAddTable_int(): table public.my_table has no index
mt_idx_14
This will normally occur with candidate primary keys; apparently
the index specified is not available on this node.
Slony-I: setAddTable_int(): table public.my_table not found
Worse than an index missing, the whole table is missing. Appar‐
ently whatever process you were using to get the schema into
place everywhere didn’t work properly.
Slony-I: setAddTable_int(): public.my_view is not a regular table
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...)
Slony-I: setAddTable_int(): set 4 not found
You need to define a replication set before assigning tables to
it.
Slony-I: setAddTable(): set 4 has remote origin
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: cannot add table to currently subscribed set 1
Slony-I does not support adding tables to sets that are already
participating in subscriptions. Probably you need to define a
new set to associate additional tables to.
On the origin node, this operation requires a brief exclusive lock on
the table in order to alter it to add the replication trigger. On sub‐
scriber nodes, corresponding locking takes place at the time of the
SUBSCRIBE_SET event.
This command was introduced in Slony-I 1.0
17 November 2008 SET ADD TABLE(7)