https://bugzilla.wikimedia.org/show_bug.cgi?id=37225

--- Comment #44 from Richard Guk <[email protected]> 2012-06-24 00:34:40 
UTC ---
I've no idea which server log items might be relevant, but we could narrow down
the timeframe.

If you have not already done so, could you extract the relevant recentchanges
entries (or a large sample) spanning the days around 2012-05-30?

The table is purged after 30 days (at least on enwiki), so a database query now
would 
be useful to preserve a comprehensive record for future analysis, even if your
current focus is on logging within the current code.

For example, the rough SQL below should identify most duplicate or
edit-conflicting rows in recentchanges:

* including edit/create entries which have a prior byte length of zero or null

* but excluding possible page creates (where there is no recent prior
edit/create)

* and excluding possible unblanked pages (where there exists any recent edit
with a new byte length of zero, or there is no recent prior edit).

SELECT trc.* from recentchanges trc, ( SELECT rc_cur_id, MIN(rc_id) AS
rc_id_min, MIN(COALESCE(rc_new_len,0)) from recentchanges WHERE rc_new_len>0
AND rc_type<=1 GROUP BY 1 HAVING MIN(COALESCE(rc_new_len,0))>0 ) trcmin WHERE
(trc.rc_old_len=0 OR trc.rc_old_len IS NULL) AND trc.rc_type<=1 AND
trc.rc_cur_id=trcmin_rc_cur_id AND trc.rc_id>trcmin.rc_id_min

For simplicity, the above query ignores edits which do not have a valid older
entry on recentchanges; and ignores all pages which have recently been blanked.

Hope that's helpful; apologies for being presumptious if not! With the 30 day
purging time imminent, I thought it best to make a specific suggestion.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Reply via email to