On Tue, 2005-05-10 at 17:21, Christopher Browne wrote:
> Scott Marlowe wrote:
> 
> >UPDATE UPDATE UPDATE UPDATE
> >
> >The third line here is what's killing it.  The update.
> >
> >ALTER TABLE BUSINESSREQUESTSUMMARY ADD AVERAGERESPONSETIME_
> >NUMERIC(8,0);
> > ALTER TABLE BUSINESSREQUESTSUMMARY ADD LOWESTRESPONSETIME_
> >NUMERIC(8,0);
> > ALTER TABLE BUSINESSREQUESTSUMMARY ADD HIGHESTRESPONSETIME_
> >NUMERIC(8,0);
> > UPDATE BUSINESSREQUESTSUMMARY SET
> >AVERAGERESPONSETIME_=AVERAGERESPONSETIME,
> >LOWESTRESPONSETIME_=LOWESTRESPONSETIME,
> >HIGHESTRESPONSETIME_=HIGHESTRESPONSETIME;
> >
> >Does that help?
> >  
> >
> Not really.  The problem is presumably specifically related to your
> schema, and likely to some mismatch between what is on the origin versus
> the subscribers.

Not likely.  I set up the slave database with this command:

pg_dump -s -U $REPLICATIONUSER -h $MASTERHOST $MASTERDBNAME | psql -U
$REPLICATIONUSER -h $SLAVEHOST $SLAVEDBNAME

Just before setting up slony and starting replication.  The table in
those two schemas is an exact duplicate.  I will try setting up a very
simple test case...

> 
> There's probably something breaking about
> 
>  UPDATE BUSINESSREQUESTSUMMARY SET
> AVERAGERESPONSETIME_=AVERAGERESPONSETIME,
> LOWESTRESPONSETIME_=LOWESTRESPONSETIME,
> HIGHESTRESPONSETIME_=HIGHESTRESPONSETIME;
> 
> but that'll be specific to your environment...

Note that two three columns were created in the previous three lines of
DDL, which all replicated cleanly to both master and slave in the set. 
Could it be that they're brand new causing the problem?