On 8/26/2010 11:03 AM, Guy Helmer wrote:
>> It looks like there is one delete for user_id=34 missing. This could be caused by a corrupted index on sl_log_1. Can you do a
>> 
>>    REINDEX _replication.sl_log_1;
>> 
>> and then repeat that SELECT?
>> 
> 
> I had already manually intervened in the slave's table to get the replication working again, so the sl_log_1 table was empty.  I have run the REINDEX TABLE _replication.sl_log_1 command, and the table is still empty...

Sure.

The thing is that I recall from long ago a case where I had a corrupted 
sl_log_x index. I forgot which PG and/or Slony versions that was. The 
specific in that case was that one and the same heap tuple showed up in 
an index scan (same ctid), but not in a sequential scan. Since then we 
have moved away from deleting and vacuuming sl_log_x and simply truncate.

What I am wondering is if you have encountered a similar case where an 
index tuple points to the wrong row and thus, the row that is missing 
isn't found in that index scan. You won't get a duplicate row if the 
wrong one it is pointing to is a deleted one.


Jan

-- 
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin