Yeh, that's pretty much the same problem I'm having (upgrade script is
pretty much the same, too).  I found that if you drop all of your
constraints on the slave schema when you import it (before initializing
the node), you might get a bit farther but that's just a work around;
you're just avoiding the fact that for some reason postgres seems to
think that some triggers are deferred when they actually aren't.

Very difficult to debug since this only happens at commit--so you can't
go through the script by hand then rollback (that always works:).  Still
poking around the postgres code to figure out why it is doing that.

Matt
On Tue, 2005-05-10 at 16:41 -0500, Scott Marlowe wrote:
> On Tue, 2005-05-10 at 16:21, Christopher Browne wrote:
> > Scott Marlowe wrote:
> > 
> > >None of it ever runs.  IS there some strange requirement for execute
> > >script I?m missing?
> > >  
> > >
> > Just to make things clear...   The script _IS_ taking effect on node #1,
> > the origin, but NOT on node #2 the subscriber.
> 
> Correct, node 1 updates, node 2 does not.
> 
> > Q1:  Have you taken a look at the logs for the respective nodes?
> 
> ERROR:  could not find trigger 3895508
> LOG:  unexpected EOF on client connection
> LOG:  unexpected EOF on client connection
> 
> Note that both of these databases are on the same cluster.  The original
> problem showed up in our staging environment, which has two seperate
> machines.  I am attempting to replicate this problem on my workstation
> so that?s why it?s on one cluster.
> 
> > A "wild guess" is that something in the script breaks, and slon falls
> > over at that point.
> 
> That certainly looks like what?s happening.
> 
> > Q2:  Does replication continue to take place after this?
> 
> No
> 
> > I suspect not.
> 
> You suspected correctly.  :)
> 
> > And I expect that things will fall over, over and over, until you can
> > fix things so that the DDL_SCRIPT event can run without failing.
> 
> I'll try to figure out what's making it fail.  Still, this seems like a
> poor failure mode.  It would see to me that since one DDL script is
> failing, the other should be rolled back.  natch?
> 
> > In any case, logs for node #2 are vital to the diagnosis.
> 
> Should I turn up the verbosity a bit in the logging and see if I can get
> more data?  I'll try to figure out exactly what in the ddl script is
> breaking the update...
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at gborg.postgresql.org
> http://gborg.postgresql.org/mailman/listinfo/slony1-general
> 

-- 
Matthew Rich <mrich at tigris.org>