Provided by: slony1-2-doc_2.0.7-3build1_all bug


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


       SET ADD TABLE (options);


       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.

       SET ID = ival
              ID of the set to which the table is to be added.

       ORIGIN = ival
              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.

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

       FULLY QUALIFIED NAME = 'string'
              The full table name as described in SLONIK 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 SLONIK 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].


       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. Apparently whatever
              process you were using  to  get  the  schema  into  place  everywhere  didn't  work

       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.   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 the replication trigger. On  subscriber  nodes,  corresponding  locking
       takes place at the time of the SUBSCRIBE_SET event.


       This command was introduced in Slony-I 1.0

                                         3 December 2011                  SLONIK SET ADD TABLE(7)