On Aug 26, 2010, at 8:11 AM, Guy Helmer wrote:

> On Aug 23, 2010, at 2:42 PM, Steve Singer wrote:
> 
>> Guy Helmer wrote:
>>> I'm seeing something odd occasionally on a fairly new slony1 (1.2.20) replication set involving one slave.  At times, the application inserts a record to a particular table, updates the record several times, and then deletes the record, sometimes in a fairly quick succession (but not always).
>>> When I run the test-slony-state script, sometimes I find that the replication is failing, and when I look deeper, I find that Slony is having trouble replicating the changes to this table because of rows in the slave table that shouldn't be there.  After I manually remove the conflicting rows, Slony is then able to finish the backlogged replication.
>>> Is there anything in particular I should look for in the log file prior to this problem?
>> 
>> 
>> Shortly after the problem happens your going to want to look at sl_log_1  sl_log_2 and sl_event to figure out what was going on.
>> 
>> You want to find the what sync the delete should have been part of, and what sync the failing insert was part of and try to figure out why the delete wasn't applied to the slave by the time it tried the insert.
>> 
>> You would also want to look at the logs slon generates to see if that sync did get applied and look in sl_confirm to verify that.
>> 
>> 
>> Honestly I am somewhat suspect that something else isn't going on I find your description somewhat hard reconcile with how things work.
>> 
> 
> Thanks for the advice.  It has happened again.  Due to the timing of the issue corresponding somewhat closely with a software update where we took the database & slony down for the maintenance, I am wondering if we might be taking things down in incorrect order...

Just to wrap this thread up cleanly, I found there was a TRUNCATE command issued in our PHP code on the table in question.  I had not expected that, so I didn't look for it until today.

Thanks everyone for the help and suggestions!

Guy--------
This message has been scanned by ComplianceSafe, powered by Palisade's PacketSure.