Sync_client errors upgrade from 2.3.16 to 2.4.5

[Bron Gondwana]

On Sat, Dec 04, 2010 at 01:59:33PM +1030, Stephen Carr wrote:
> Dear All
> 
> I had a problem last week upgrading 2.3.16 to 2.4.4 due to a CRC bug.
> 
> I have now updated from 2.3.16 to 2.4.5 with no major problems but I am 
> getting a massive number of records of the type below - I will have to 
> monitor the log size.
> 
> The sync_client and replica have the same time ( actually the replica 
> gets it date off the sync_client every 2 minutes).
> 
> Also I get a very few like this
> 
> Dec  4 13:58:12 brooks sync_client[17782]: inefficient replication (17 > 
> 15) user.user1
> Dec  4 13:58:14 brooks sync_client[17782]: inefficient replication (12 > 
> 10) user.user2

you might get them at the start.  Unless you have immediate expunge
turned on, you shouldn't get too many after that.
 
> Dec  4 13:55:09 brooks sync_client[17782]: RECORD MISMATCH WITH REPLICA: 
> more recent on replica
> Dec  4 13:55:09 brooks sync_client[17782]: master uid:31107 modseq:1 
> last_updated:1276248211 internaldate:1276248211 flags:(\Seen)
> Dec  4 13:55:09 brooks sync_client[17782]: replica uid:31107 modseq:1 
> last_updated:1287574229 internaldate:1276248211 flags:(\Seen)

There you go - higher "last_updated" on the replica.  This isn't really
a problem - it will clean up with time as the last_updated fields get
in sync between the two ends.

I did debate not counting last_updated for the purpose of replication
sync, but decided it's actually useful for determining which end is more
recent, and you can't do that if the replica always looks newer!

Bron.