Provided by: slony1-doc_1.2.14-1ubuntu1_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
       currently be subscribed by any  other  node  -  that  functionality  is
       supported 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
              tables 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’
       );

ERROR MESSAGES

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

LOCKING BEHAVIOUR

       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.

VERSION INFORMATION

       This command was introduced in Slony-I 1.0

                               19 September 2008              SET ADD TABLE(7)