Hmmmm.  I have now managed to get the duplicate insert happening
randomly in different places.  I suspect this is some sort of race
condition, as it is not entirely predictable when I will first encounter
an error.

I guess the unusual thing I am doing from slony's perspective is
combining a bunch of ddlscript commands with normal slony-logged dml
operations.  The time that I can guarantee to get the error is after a
fairly long-running (several seconds) series of ddl.  Interestingly, the
duplicate log record has already appeared (been comitted) at the
subscriber while the dml still appears to be running.

Is this an absolute no-no, have I stumbled upon a bug, or am I just
being dense and missing something?

For now, I am going to manage the logging in a separate transaction.
This sucks from a transaction integrity point of view but practically
speaking is not likely to cause us problems.

If anyone is interested in pursuing this, let me know what I can do to
help.

__
Marc

On Mon, 2006-05-15 at 14:39 -0700, Marc Munro wrote:
> Moving the insert to the start of the transaction solved the logtrigger
> not firing problem.  I now have a new symptom: on activating the new
> partition my insert into the log table is attempted more than once at
> the subscriber node, aborting the sync.
> 
> Everything at the provider node is fine.
> 
> Activation of the partition consists of:
> - checking that the old temporary replication set (which was used to
> bring the partition in to the main set) is gone, by querying the
> subscribers using dblink
> - creating a view on the new partition using ddlscript
> - creating instead-of views on the new partition using ddlscript
> 
> As other state transitions appeared to work correctly, I am baffled by
> this behaviour.  Investigations continuing...
> 
> __
> Marc
> 
> On Mon, 2006-05-15 at 10:03 -0700, Marc Munro wrote:
> > On Mon, 2006-05-15 at 11:17 -0400, Jan Wieck wrote:
> > > 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.
> > > 
> > I'm pretty sure this is not it.  My log table was already successfully
> > merged and synced prior to the state transition call and I am not
> > performing any merge within my state transition.
> >
> > I am next going to try moving the insert to the start of the transaction
> > to see if the logtrigger dislikes firing after a ddlscript call.
> > 
> > __
> > Marc
> > 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : http://gborg.postgresql.org/pipermail/slony1-general/attachments/20060516/0f5b8d2b/attachment-0001.bin