Provided by: slony1-doc_1.2.15-1_all bug
 

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)