I suspect this is yet another failed attempt to merge before the 
ENABLE_SUBSCRIPTION has been processed. I guess some day we will have to 
remove the whole ENABLE_SUBSCRIPTION part but instead let the 
SUBSCRIBE_SET travel from the origin instead.


Jan


On 5/12/2006 8:16 PM, Marc Munro wrote:

> I have an application that builds new partitions on a monthly basis, and
> adds them to the primary replication set.  Each new partition goes
> through a number of states before becoming the active partition with
> each state change logged in a replicated table.
> 
> My log of state changes is not being properly replicated.  If I manually
> insert into the log table, the change gets successfully replicated.  If
> my automated script does it, the change is not replicated.
> 
> The state transitions involve creating new temporary replication sets,
> creating new tables at each node, adding tables to the temporary
> replication set, subscribing sets, merging sets, and so on.
> 
> A state transition is performed within a single transaction and may
> involve calls to _slony_schema.ddlscript().  All state transitions
> finish, if successful, with an insert into my log table.
> 
> Is the use of ddlscript within the same transaction as the insert
> somehow disabling the normal logtrigger actions?  Any other
> possibilities?  Is there a simple workaround?
> 
> All ideas and suggestions are welcomed.  Thanks.
> __
> Marc
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at gborg.postgresql.org
> http://gborg.postgresql.org/mailman/listinfo/slony1-general


-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #