In the "current limitations" section of the documentation it states that
"In addition, any other triggers and rules on replicated tables are
suppressed on the subscribers: This is done by pointing them, in the
system table, to the primary key index instead of to the table itself."
When implementing table partitioning, part of the process is to create
rules on the master table to redirect operations such as inserts to the
proper child table.  Check constraints on each child table enforce rules
for where rows of data are stored, but it is the rule set on the master
table that allows for inserts/updates on the master table to make their
way to the proper child.

 

Does this mean that Slony-I is not compatible with partitioned tables in
PostgreSQL?

1.5. Current Limitations

Slony-I does not automatically propagate schema changes, nor does it
have any ability to replicate large objects. There is a single common
reason for these limitations, namely that Slony-I collects updates using
triggers, and neither schema changes, large object operations, nor
TRUNCATE requests are able to triggers suitable to inform Slony-I when
those sorts of changes take place. As a result, the only database
objects where Slony-I can replicate updates are tables and sequences. 

Note that with the use of triggers comes some additional fiddling around
with triggers. On the "origin" for each replicated table, an additional
trigger is added which runs the stored procedure schemadoclogtrigger( )
<http://www.slony.info/documentation/function.logtrigger.html> . On each
subscriber, tables are augmented with a trigger that runs the
schemadocdenyaccess( )
<http://www.slony.info/documentation/function.denyaccess.html>
function; this function prevents anything other than the slon
<http://www.slony.info/documentation/slon.html>  process from updating
data in replicated tables. In addition, any other triggers and rules on
replicated tables are suppressed on the subscribers: This is done by
pointing them, in the system table, to the primary key index instead of
to the table itself. This represents something of a "corruption" of the
data dictionary, and is why you should not directly use pg_dump to dump
schemas on subscribers. 

 

 

Thanks,

 

Keaton

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.slony.info/pipermail/slony1-general/attachments/20070411/12b90284/attachment.htm