Ow Mun Heng <Ow.Mun.Heng at wdc.com> writes:
> Hi,
>
> I'm still researching my options regarding using slony to replicate
> partitions.
>
> I've gotten pointers in that slony doesn't really do the partitioning
> per-se, but does support their replication via individual tables. (this
> is OK for me)
>
> then Christopher Brown pointed me to a link (no web-access at the
> moment) and the usage of 
>
> add_empty_table_to_replication()
> which I looked at the SQL and seems like based on my understanding, it
> will
>
> 1) check if the set exists 
> (i'm a bit confused here, Does this mean that it will check if the
> parent table is already currently in a replication set? How does it know
> which one is the origin set? How do I call it? It has 5 field variables)
> 2) locks the origin table
> 3) check to see if the new (child) table to be replicated is empty using
> a "select 1 from x limit 1"
>
> is the add_empty_table_to_replication means that I need to manually
> trigger it using slonik? (weekly child table)
>
> replicate_partition()
> This one seems more understand-able (to me)
> 1) it looks in pg_class for the parent table of the set
> 2) it gets the parent table's replications
> 3) calls add_empty_table_to_replication()
>
> all in all, I still don't have much idea how to call them.

I set up the two functions to address two "functional views" for this:
  a) add_empty_table_to_replication() is more generic, providing a way to add
     an empty table to a replication set.

     In response to your confusion about 1), this function does NOT
     check for parentage of the table; its purpose is to add ANY empty
     table to replication, irrespective of use of table inheritance.
     The point of having the set ID is that each replicated table MUST
     be tied to a replication set, so this function needs to have a
     way to specify that.

In contrast, replicate_partition() provides a "cooked" perspective on
this; it provides a "user interface" directed towards adding in
inherited tables.  Note that it has fewer arguments; it doesn't need
to have a replication set specified, because that may be inferred
based on the "parent" table's metadata.

Thus, replicate_function() is quite a bit simpler, and, since it's
mostly doing validation of the data it's passing to
add_empty_table_to_replication(), that should *improve* reliability of
it.

Basically, what you would need to do, weekly, is to run a slonik
"execute script" script where the SQL script consists of something
similar to what's in tests/testpartition/gen_ddl_sql.sh:

-> create the new table, with indication of inheritace from the parent;

-> create a rule to indicate when data gets inserted into the new
   table, assuming you're using rules to control this;

-> run replicate_partition() on this newly-created table.
-- 
let name="cbbrowne" and tld="linuxfinances.info" in name ^ "@" ^ tld;;
http://cbbrowne.com/info/oses.html
"We English-speaking peoples should   keep hold of the essential  fact
about foreign languages: They exist to make us laugh."
-- John Derbyshire