[06:42:55] <rohit-dua>	 cgi-bin in tools-lab does'nt seem to work for work. I added a simple python cgi script as index.cgi with chmod +x, but it does not work..
[06:43:26] <rohit-dua>	 what i receive is 
[06:43:27] <rohit-dua>	 Four hundred and four!
[06:44:19] <hedonil>	 rohit-dua: cgi-bin folder is a "legacy" folder from the old apache setup
[06:44:50] <rohit-dua>	 hedonil: ok, how do I run python- cgi
[06:45:12] <hedonil>	 put everything in public_html or subfolders
[06:45:38] <rohit-dua>	 will .cgi work inside public_html?
[06:46:09] <hedonil>	 if you name a file foo.py it will work out of the box
[06:48:48] <hedonil>	 rohit-dua: if you want to execute cgi-files with other extensions, you have to configure them 
[06:48:49] <hedonil>	 https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/Help#Web_services
[06:50:43] <rohit-dua>	 hedonil: thank you, :-)
[06:51:00] <hedonil>	 rohit-dua: my pleasure ;)
[13:30:21] <wikibugs>	 3Wikimedia Labs / 3tools: Tool Labs: Provide anonymized view of the user_properties table - 10https://bugzilla.wikimedia.org/58196#c36 (10Liangent) (In reply to Luis Villa (WMF Legal) from comment #34) > Sorry for the slow response, Liangent - email slipped through the cracks for > some reason. Q: what's the...
[13:44:34] <liangent>	 hello Coren
[13:49:00] <liangent>	 the crontab fixer is stupid. I use a wrapper script for a jstart call and was using the wrapper script directly in crontab, but it now prefixes it with /usr/bin/jsub :(
[13:49:55] <valhallasw>	 liangent: that shouldn't be a huge issue, right? It just takes slightly longer to start.
[13:52:01] <liangent>	 valhallasw: yeah and there's another thing: arguments need to be escaped (again) to workaround https://bugzilla.wikimedia.org/show_bug.cgi?id=48811
[13:52:54] <valhallasw>	 huh? your wrapper script takes arguments?
[13:58:06] <liangent>	 valhallasw: not the same problem, but this can be an issue. and in my case there were https://bugzilla.wikimedia.org/show_bug.cgi?id=48811 hits and I didn't use SGE for then yet. wrapper script is used in some other lines
[13:58:14] <liangent>	 *for them
[13:58:44] <valhallasw>	 liangent: right, so build a wrapper script for those?
[13:59:01] <valhallasw>	 that's what the crontab fixer should do, actually, IMO
[14:00:11] <liangent>	 crontab fixer should create wrapper scripts based on crontab lines, and replace those lines with "jsub wrapper-script-1.sh" ?
[14:01:06] <valhallasw>	 yeah
[14:11:26] <liangent>	 actually .. ssh tools-submit /usr/bin/crontab my.crontab.file bypasses the fixer
[14:11:53] <valhallasw>	 yes, and then Coren will find you and hit you with a stick :-p
[14:35:32] <liangent>	 curl http://tools.wmflabs.org/xxx doesn't work in ToolLab
[14:35:52] <liangent>	 curl http://tools-webproxy.eqiad.wmflabs/xxx works, but I'm not sure whether this will keep working in the future
[14:37:11] <valhallasw>	 liangent: https://bugzilla.wikimedia.org/show_bug.cgi?id=54052
[14:37:53] <liangent>	 valhallasw: thanks
[16:10:53] <wikibugs>	 3Wikimedia Labs: [Regression] wikitech.wikimedia.org is sending empty Echo notification emails - 10https://bugzilla.wikimedia.org/53778#c3 (10Maarten Dammers) This is fairly annoying. It should at least contain the message you see when you sign in to Wikitech.
[16:38:18] <Beetstra>	 Since I don't know where else to ask either: in which Bugzilla category would a bug in "Javascript-enhanced contributions lookup 0.2" fall ??
[16:58:52] <siglar>	 Hi. When I run "crontab -e" y get this warning: "You (tools.ralgisbot) are not allowed to use this program (crontab)".
[16:59:22] <siglar>	 I've never had this problem before.
[16:59:51] <valhallasw>	 the crontab system was recently changed
[16:59:58] <valhallasw>	 but a tool should be able to edit crontabs
[17:00:08] <valhallasw>	 (users are no longer allowed to have a crontab)
[17:01:28] <Coren>	 siglar: For some reason, you part is hitting /usr/bin before /usr/local/bin
[17:01:44] <Coren>	 siglar: Use /usr/local/bin/crontab explicitly, or just 'xcrontab'
[17:02:36] <scfc_de>	 Beetstra: What's the URL?
[17:02:38] <Coren>	 valhallasw: And no, I'd only use the stick on people who circumvent the edit script to add non-grid jobs.  It's meant to provide a quick fix to newbies and/or users who don't read documentation.
[17:02:54] <valhallasw>	 Coren: ah :-p
[17:02:59] <siglar>	 Thank you, Coren. xcrontab worked :)
[17:08:51] <wikibugs>	 3Wikimedia Labs / 3tools: Tool Labs: Provide anonymized view of the user_properties table - 10https://bugzilla.wikimedia.org/58196#c37 (10Nemo) Small/medium/big wikis have 10/100/1000 thousands total pages or more. You can see the lists at https://noc.wikimedia.org/conf/ The lists were originally made as rou...
[17:23:43] <Beetstra>	 scfc_de: which URL
[17:24:33] <Beetstra>	 scfc_de: do you mean the wiki url:  https://en.wikipedia.org/wiki/Special:Contributions/198.24.31.121/16 <- does not work correctly (make sure you have the javascript lookup enabled
[17:30:16] <scfc_de>	 Beetstra: I don't see an error on that page, and I can't find "Javascript-enhanced contributions lookup" on https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsection-gadgets.  Is that "Allow /16, /24 and /27 – /32 CIDR ranges on Special:Contributions forms"?
[17:30:51] <Beetstra>	 The error is that there are 2 IPs in that range who were active in 2014 .. but you don't see them ..
[17:31:16] <Beetstra>	 scfc_de: yes, I think that that is the gadget thingy
[17:32:51] <scfc_de>	 Beetstra: Ah, okay.  Well: Don't know if that is an error :-).  Preferences says "Please report any issues here." with here = https://en.wikipedia.org/wiki/MediaWiki_talk:Gadget-contribsrange.js#Update_.28October_2008.29
[17:33:25] <Beetstra>	 Yeah, I did not see that until now .. (filed the bug already) .. 
[17:33:34] <Beetstra>	 I think line 49 needs a '+1'
[17:34:15] <Beetstra>	 scfc_de: https://en.wikipedia.org/wiki/MediaWiki_talk:Gadget-contribsrange.js#IP_wildcards_and_CIDR_ignoring_an_address
[17:34:21] <Beetstra>	 but not properly fixed, apparently
[17:45:51] <hedonil>	 Coren: new proxy is in place. How about da logs? I wanna eat 'em up ;)
[18:18:48] <scfc_de>	 hedonil: https://wikitech.wikimedia.org/wiki/User_talk:Petrb#m:toollabs:awstats
[18:19:04] <scfc_de>	 (But I think there's still a bug of yours open?)
[18:20:16] <hedonil>	 scfc_de: yeah. I want to assimilate them => one entity :-)
[18:22:21] <hedonil>	 https://bugzilla.wikimedia.org/show_bug.cgi?id=59222
[18:30:36] <wikibugs>	 3Wikimedia Labs: Request to access redacted webproxy logfiles of (Tool) Labs - 10https://bugzilla.wikimedia.org/59222#c4 (10metatron) Now that new YuviProxy is in place, I just need access to logdumps (IP's stripped off). sed & awk will do the rest of the job.
[18:54:41] <petan>	 @replag
[18:54:41] <wm-bota>	 Replication lag is approximately 00:00:00.5231610
[18:55:01] <saper>	 atomic precision
[18:55:12] <valhallasw>	 Appoximately with 7 digits after the decimal point. Awesome
[18:55:18] <petan>	 hehe
[18:56:05] <wikibugs>	 3Wikimedia Labs / 3(other): Database dewiki_p on dewiki.labsdb : views hashs and links broken - 10https://bugzilla.wikimedia.org/55708#c4 (10Tim Landscheidt) (In reply to Andre Klapper from comment #3) > metatron: Is this still a problem or can this ticket be closed nowadays?  Still around:  | MariaDB [dewik...
[18:59:02] <scfc_de>	 Reminds me of when German news media replay reports from across the pond: "The cyclist flew over 100 feet (30.48 meters) through the air." :-)
[19:14:24] <Eccenux>	 Hi. Could someone re-label this form: https://wikitech.wikimedia.org/w/index.php?title=Special:NovaServiceGroup&action=addservicegroup&projectname=tools
[19:14:41] <Eccenux>	 It should say add tool, not group.
[19:14:55] <Simeondahl>	 Greetings, can someone help me with a bot on one of out channels? Thanks.
[19:15:01] <Eccenux>	 It's confusing otherwise.
[19:15:06] <valhallasw>	 Eccenux: except the labs terminology is 'group' and not 'tool'.
[19:15:16] <valhallasw>	 ('service group', specifically)
[19:16:19] <Eccenux>	 Yeah, but group is "tool.<Service group name>" and it says "Create New Tool" in the link
[19:17:06] <valhallasw>	 Only on tool labs -- it's actually called <projectname>.<servicegroupname>. But even then, I think it makes sense to have a function to use TL terminology instead.
[19:19:19] <scfc_de>	 +1.  Needs to be added to Extension:OpenStackManager, though, so no trivial change.
[19:19:53] <Eccenux>	 Ah, I see where this came from. Still it adds more then just a group. At least in terms of Tool Labs.
[19:20:53] <valhallasw>	 scfc_de: or just using site javascript
[19:27:49] <valhallasw>	 now who is sysop at wikitech...
[19:28:39] <valhallasw>	 Coren: could the contents of https://wikitech.wikimedia.org/wiki/User:Merlijn_van_Deen/common.js be added to the central common.js?
[19:29:58] <valhallasw>	 scfc_de ^ :-)
[19:45:15] <scfc_de>	 valhallasw: No can do, I'm just an contentadmin :-).
[21:14:49] <valhallasw>	 oh, Coren, https://gerrit.wikimedia.org/r/#/c/102721/ ?
[21:28:41] <Damianz>	 Is there replication lag or something? Seem to be more than usual missing revision data when checking edits
[21:30:54] <hedonil>	 Damianz: Hmm. some minor wikis have a certain lag, according to Betacommand 's tool  https://tools.wmflabs.org/betacommand-dev/cgi-bin/replag
[21:31:09] <Damianz>	 enwiki looks alright though
[21:37:00] <rotpunkt>	 hi, I have some problem with "webservice start", always worked before today
[21:37:44] <rotpunkt>	 "webservice status" says: "Your webservice is scheduled: queue instance "continuous@tools-exec-06.eqiad.wmflabs" dropped because it is temporarily not available"
[21:38:13] <rotpunkt>	 what can I do?
[21:39:03] <hedonil>	 rotpunkt: grid engine seems to be confused ;) wrong queue
[21:39:11] <hedonil>	 rotpunkt: try again
[21:39:34] <rotpunkt>	 ok thanks!
[21:42:49] <Damianz>	 Hmm... definatly seem to be missing things that should be there *digs into the database*
[21:49:16] * Damianz  wonders if Draft: is a namespace on enwiki... which should explain this one

[21:55:52] <wikibugs>	 3Wikimedia Labs: [Regression] wikitech.wikimedia.org is sending empty Echo notification emails - 10https://bugzilla.wikimedia.org/53778 (10Tim Landscheidt) a:5Ryan Lane>3None
[21:56:05] <wikibugs>	 3Wikimedia Labs: [Regression] wikitech.wikimedia.org is sending empty Echo notification emails - 10https://bugzilla.wikimedia.org/53778#c4 (10Tim Landscheidt) With Ryan being elsewhere, unassigning for the moment.
[21:56:20] <wikibugs>	 3Wikimedia Labs: [Regression] wikitech.wikimedia.org is sending empty Echo notification emails - 10https://bugzilla.wikimedia.org/53778 (10Tim Landscheidt) 5ASS>3NEW
[22:05:33] <Cyberpower678>	 springle, ping
[22:05:41] <Cyberpower678>	 Coren, ping
[22:06:21] * Cyberpower678  is getting impatient.

[22:17:21] <wikibugs>	 3Wikimedia Labs / 3(other): archive_userindex on replication server not indexed well.  Takes 10s of seconds to execute a query. - 10https://bugzilla.wikimedia.org/63777#c1 (10Cyberpower678) p:5Unprio>3High s:5normal>3major BUMP.  I've opened this almost a month ago with no initial comments.  Revision...
[22:18:50] <wikibugs>	 3Wikimedia Labs / 3(other): archive_userindex on replication server not indexed well.  Takes 10s of seconds to execute a query. - 10https://bugzilla.wikimedia.org/63777 (10Cyberpower678) s:5major>3normal
[22:52:04] <Betacommand>	 hedonil: you there?
[22:52:16] <Cyberpower678>	 Betacommand, he is.
[22:52:21] <hedonil>	 Betacommand: yep
[22:52:49] <Betacommand>	 hedonil: my tool just shows the time since the last recorded edit on that wiki to calculate lag 
[22:53:13] <Betacommand>	 IE the most recent item in the rc table
[22:53:25] <hedonil>	 is this a bad thing ? ;)
[22:53:29] <Betacommand>	 not 100% accurate for small wikis
[22:53:34] <hedonil>	 hehe
[22:53:44] <hedonil>	 it's a nice tool
[22:54:01] <hedonil>	 some graphics would make it even more wonderful ;)
[22:54:05] <Betacommand>	 thats why it may show high values for some of the smaller wikis while its not an issue
[22:54:15] <hedonil>	 ahh ok
[22:54:35] <wikibugs>	 3Wikimedia Labs / 3tools: Tool Labs: Provide anonymized view of the user_properties table - 10https://bugzilla.wikimedia.org/58196#c38 (10Krinkle) Changing the timestamp in this table based on wiki size would be a mistake in my opinion. It would make the data too arbitrary and hard to maintain. It also proba...
[22:55:23] <Betacommand>	 IE jvwiktionary has parse edits and shows a inaccurate high value
[22:56:44] <Betacommand>	 hedonil: Im not big into graphics, if you use the non-https version you can sort the table
[22:57:04] <Betacommand>	 loading via https breaks that js
[22:58:16] * Betacommand  reminds self to poke coren about protocol relative programming

[23:00:45] <hedonil>	 Betacommand: maybe if you omit the protocol (http:) this will fix it ?  https://tools.wmflabs.org/paste/view/6a6b533e
[23:02:09] <hedonil>	 Cyberpower678: that's the output from optimizer
[23:02:12] <hedonil>	 https://tools.wmflabs.org/paste/view/b698b560
[23:02:32] <hedonil>	 a little bit screwed
[23:03:46] <Cyberpower678>	 Hmm...
[23:03:57] <hedonil>	 but anyway... the problem is, MySQL Optimizer uses index `usertext_timestamp` as prefered index
[23:05:58] <scfc_de>	 Re replag, there should be graphics at ganglia.wmflabs.org (though the reporting script was probably disabled by the crontab change).
[23:08:43] <scfc_de>	 hedonil: There are different tables in the replicas and I'm not sure if you can assume the same results for them (though I don't have enough MySQL knowledge why in the first place you need different tables for different indexed queries anyway; I would assume that you just use one table with two indexes).
[23:09:31] <hedonil>	 scfc_de: MySQL only chooses /one/ index per query (as rule of thumb)
[23:09:37] <hedonil>	 https://tools.wmflabs.org/paste/view/e9906b7a
[23:10:19] <Cyberpower678>	 scfc_de, and the query we use, uses the wrong index.  Hence rev_user, and ar_user being slow on revision_userindex, and archive_userindex
[23:11:01] <Betacommand>	 hedonil: Ive made a few tweaks, not sure when Ill have time to push the changes live
[23:11:09] <Cyberpower678>	 scfc_de, if we could tell the DB what index to use when we query, it would solve our problems, but it won't let us.
[23:11:12] <scfc_de>	 hedonil: Sure; but we have the views/tables revision and revision_userindex.  I would assume that you just have one table revision with different indexes and MySQL figures out on its own which index to use depending on the clauses you provide.
[23:12:50] <Betacommand>	 Cyberpower678: can you specify the indexed field early in the query, it should force it to use that index
[23:13:13] <Cyberpower678>	 Betacommand, apparently doesn't work on views like the replication DBs.
[23:13:38] <Cyberpower678>	 It's really slowing down the edit counter.
[23:13:44] <Betacommand>	 Cyberpower678: it should, I know it worked like that on the TS
[23:13:59] <Cyberpower678>	 MBisanz's stats loaded in 114 seconds.  That is excessively high.
[23:14:13] * Cyberpower678  is beginning to miss the tool server.

[23:14:31] <hedonil1>	 darn
[23:14:46] <Cyberpower678>	 hedonil1, need scroll back?
[23:15:10] <hedonil1>	 Hmm. don't think so
[23:15:25] <Cyberpower678>	 What was the last thing you got?
[23:15:41] <hedonil1>	 there are ways (my last words)
[23:15:44] <hedonil1>	 heh
[23:16:50] <Cyberpower678>	 scfc_de, I see you added yourself to the CC list of the bugzilla I filed.
[23:16:58] <hedonil1>	 1st thing was to make sure, the underlying index is accessible  in view  revision_userindex
[23:17:02] <hedonil1>	 https://tools.wmflabs.org/paste/view/ac820c40
[23:17:11] <hedonil1>	 which is ok
[23:17:49] <hedonil1>	 2nd thing is to force MySQL otimizer to /not/ use this index as default
[23:18:10] <hedonil1>	 which can be accomplished in two ways
[23:18:43] <hedonil1>	 1. access the table directly and use  USE INDEX(foo) statement
[23:18:55] <hedonil1>	 -> can't be done
[23:19:52] <hedonil1>	 2. rewrite the query (add a join, leave something out), so MySQL optimizer changes his mind
[23:20:57] <hedonil1>	 I'll try something on my optimizer replica  "u3710__enwiki_optimizer_p"  database on enwiki.labsdb
[23:21:12] <Cyberpower678>	 hedonil1, rewrite the query how?
[23:22:00] <hedonil1>	 that's the point of matter ;-)
[23:22:31] <hedonil1>	 as said, add a random join on something additional
[23:22:46] <hedonil1>	 or something like that
[23:22:49] <wikibugs>	 3Wikimedia Labs / 3Infrastructure: install ExpandTemplates mediawiki extension @ wikitech - 10https://bugzilla.wikimedia.org/53935#c1 (10Derk-Jan Hartman) 5NEW>3RES/WOR ExpandTemplates is in core now, so this can be closed.
[23:23:23] * Cyberpower678  wants to know who's idea it was to design the replication DBs like this.

[23:23:36] <Cyberpower678>	 !newlabs
[23:23:36] <wm-bot>	 The tools project in labs another version of toolserver.  Because people wanted it just like toolserver, an effort was made to create an almost identical environment.  Now users can enjoy replication, similar commands, and bear the burden of instabilities, just like Toolserver.
[23:24:01] <Cyberpower678>	 That should be rewritten.
[23:25:06] <hedonil1>	 well, it's just... there are many indeces on revision table
[23:25:33] <hedonil1>	 and our ol' friend OPTIMIZER is choosing one for us :-)
[23:26:10] <Cyberpower678>	 To hell with optimizer.  Things in this case would seem to work better without it.
[23:26:40] <hedonil1>	 if one could use the table directly ....
[23:26:52] <scfc_de>	 For the most part, the queries in the bug report return for me in <= 0.01 s.
[23:27:14] <Cyberpower678>	 scfc_de, which table?
[23:27:19] <hedonil1>	 scfc_de: in our case it's like 20 seconds
[23:27:24] <Cyberpower678>	 Or more
[23:28:07] <scfc_de>	 SELECT COUNT(*) AS count FROM revision_userindex WHERE `rev_user_text` ='Tim.landscheidt';
[23:28:15] <scfc_de>	 SELECT COUNT(*) AS count FROM archive_userindex WHERE `ar_user_text` ='Hedonil';
[23:28:19] <scfc_de>	 enwiki_p
[23:28:39] <hedonil1>	 /not/ rev_user_text !
[23:28:44] <Cyberpower678>	 scfc_de, ok.  That's the fast one.  It's also the one we /don't/ want to user.
[23:28:44] <hedonil1>	 that's the point
[23:28:55] <Cyberpower678>	 We're trying to use rev_user
[23:28:59] <Cyberpower678>	 and ar_user
[23:29:27] <scfc_de>	 Didn't you write in the bug report that you specifically did *not* want to use rev_user?
[23:29:45] <scfc_de>	 Ah, okay, read again.
[23:29:51] <hedonil1>	 `rev_user_text` == KEY `usertext_timestamp` (`rev_user_text`,`rev_timestamp`,`rev_user`,`rev_deleted`,`rev_minor_edit`,`rev_text_id`,`rev_comment`)
[23:30:09] <hedonil1>	 that's what we are talking about
[23:30:50] <wikibugs>	 3Wikimedia Labs / 3(other): archive_userindex on replication server not indexed well.  Takes 10s of seconds to execute a query. - 10https://bugzilla.wikimedia.org/63777#c2 (10Cyberpower678) For clarity I'm not trying to use rev_user_text, or ar_user_text.
[23:31:20] <hedonil1>	 we want to get the optimizer use this index:  KEY `user_timestamp` (`rev_user`,`rev_timestamp`),
[23:31:22] <Cyberpower678>	 scfc_de, I wrote a clarification on the bug report.  I could've written the initial statement better.
[23:32:13] <scfc_de>	 Cyberpower678: The clarification was in the initial statement; I had just assumed that the two queries were the same and only repeated to show the effects of caching.
[23:32:21] <Cyberpower678>	 hedonil1, can you inspect archive's indexing keys?
[23:32:42] <scfc_de>	 hedonil1: Are you sure that index /actually/ exists on the replicas?
[23:32:44] <Cyberpower678>	 scfc_de, ok. :-)
[23:33:13] <hedonil1>	 Cyberpower678: I can check the view structure (as I did before)
[23:33:19] <hedonil1>	 scfc_de: yep
[23:33:25] <Cyberpower678>	 hedonil1, please do.
[23:33:40] <hedonil1>	 https://tools.wmflabs.org/paste/view/e9906b7a    <-- that's the running schema
[23:34:32] <scfc_de>	 hedonil1: How do you get that?
[23:34:43] <hedonil1>	 mysqldump
[23:35:13] <Cyberpower678>	 hedonil1, can you dump archive as well?
[23:35:48] <hedonil1>	 Cyberpower678: https://tools.wmflabs.org/tools-info/schemas.php?schema=enwiki
[23:37:01] <Cyberpower678>	 hedonil1, PRIMARY KEY (`ar_id`),
[23:37:01] <Cyberpower678>	   KEY `name_title_timestamp` (`ar_namespace`,`ar_title`,`ar_timestamp`),
[23:37:01] <Cyberpower678>	   KEY `usertext_timestamp` (`ar_user_text`,`ar_timestamp`),
[23:37:01] <Cyberpower678>	   KEY `ar_revid` (`ar_rev_id`)
[23:37:30] <Cyberpower678>	 hedonil1, explains why archive is total shit with ar_user queries.
[23:37:48] <hedonil1>	 yeah
[23:38:03] <hedonil1>	 no index for that :/
[23:38:27] <scfc_de>	 hedonil1: "mysqldump: Got error: 1044: "Access denied for user 'u2267'@'%' to database 'enwiki_p'" when using LOCK TABLES"
[23:38:40] <hedonil1>	 not even a preferably /not/ chosen one  ;)
[23:38:56] <hedonil1>	 scfc_de: ingore errors
[23:39:43] <hedonil1>	 scfc_de: https://tools.wmflabs.org/tools-info/misc/optimizer.sh.txt
[23:39:44] <scfc_de>	 hedonil1: Ah!
[23:40:07] <hedonil1>	 dump=$(mysqldump --defaults-file=replica.my.cnf -h $host --no-data \ 		 --lock-tables=false --ignore-table="${source_db}._counters" --force $source_db 2>/dev/null | \ 		 sed -e "s/AUTO_INCREMENT[=0-9]*//g" -e "/rc_source\|rc_moved_to_ns\|rc_moved_to_title/d" )
[23:41:18] <hedonil1>	 ... and no locks
[23:41:49] <Cyberpower678>	 brb
[23:43:54] <scfc_de>	 hedonil1: But where are the indexes?  I don't see any in "mysqldump -f -h enwiki.labsdb --no-data enwiki_p | less", and https://tools.wmflabs.org/tools-info/schemas.php?schema=enwiki doesn't mention revision_userindex?
[23:44:30] <hedonil1>	 Indeces are shown as KEY ...
[23:45:19] <scfc_de>	 On schemas.php, yes.  But where does that come from?
[23:45:46] <hedonil1>	 scfc_de: hmm leme look
[23:46:19] <hedonil1>	 maybe I added an option for the schema views on tools-info...
[23:46:29] <scfc_de>	 (The replicas are a black box for me, and thus I don't trust them a bit :-).)
[23:47:30] <scfc_de>	 hedonil1: Could it be that you added the indexes yourself after MediaWiki's tables.sql master?
[23:47:46] <hedonil1>	 :-) no
[23:49:39] <hedonil1>	 scfc_de: but for the quick look
[23:49:51] <hedonil1>	 1. mysql --defaults-file=replica.my.cnf -h enwiki.labsdb
[23:49:59] <hedonil1>	 2. use enwiki
[23:50:17] <hedonil1>	 (not the _p version !)
[23:50:35] <hedonil1>	 3. show create table revision;
[23:52:19] <hedonil1>	 which gives you something like this  https://tools.wmflabs.org/paste/view/70a83f78
[23:53:12] <scfc_de>	 Yep.  I also ran optimizer.sh, and it dumped the KEY statements to *.sql, so they are in the DB.
[23:53:38] <scfc_de>	 (And revision_userindex doesn't exist in enwiki, but only in enwiki_p, I assume.)
[23:53:56] <hedonil1>	 scfc_de: yeah, it's just a view
[23:55:49] <hedonil1>	 the only thing that matters in the views, is that whenever there's a conditional ( IF foo ), you can't access the index in the underlying table
[23:55:50] <hedonil1>	 https://tools.wmflabs.org/paste/view/ac820c40
[23:56:01] <hedonil1>	 but that is all ok
[23:58:43] <scfc_de>	 Yeah, had forgotten that it's defined at http://git.wikimedia.org/blob/operations%2Fsoftware.git/master/maintain-replicas%2Fmaintain-replicas.pl
[23:59:21] <hedonil1>	 the job is to rewrite the query to convince the optimizer to not use the one index, but the other