Provided by: slony1-doc_1.2.16-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  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].

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

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

                                  2 June 2009          SLONIK SET ADD TABLE(7)