[06:31:45] hi all [06:32:34] does somebody uses Shibboleth plugin for Mediawiki? I'm having Apache + Shibboleth correctly configured, i receive the correct Headers informations (that I've called : Remote-Sam, Remote-Mail, Remote-Display) [06:32:50] I've installed Shibboleth + PluggableAuth plugins [06:33:18] and shibboleth plugin is well configured with the above headers names … [06:33:39] however, it's not clear if PluggableAuth plugin must just be installed (wfLoadExtension) or also configured ? [06:33:51] When clicking on Login, I just get an Exception, without more info :( [07:59:19] hep, trying a bit later :) [07:59:35] does somebody uses Shibboleth plugin for Mediawiki? or has experience with ? [08:58:39] hello there [08:59:27] im in kind of a pickle [08:59:28] https://pastebin.com/V61xa5ZP [08:59:36] i get lots of errors [09:00:01] and i just installed it with no changes for testing [09:00:07] and i cant get it to work [12:10:20] trying to work on WikiEduDashboard but an error is keeping it from running locally.. http://dpaste.com/1YE4ZDX Some help would be appreciated [12:21:32] im using windows machine and trying to run ´rails s´ running into error https://github.com/halfdan/piwik-ruby-tracking.git (at master@5c733bd) is not yet checked out. Run `bundle install` first. .. can someone tell me at what location does this needs to be cloned so I can go and clone it there [15:17:58] seriously hoping the deadlock issue with postgresql in resourceloader will be solved [15:18:19] this really slays my server as hundreds of php processes get stuck timing out [15:18:56] slashdot effect generates 20 MB of postgresql error log over 15 minutes :( [19:32:40] updated my report @ T222385 [19:32:44] T222385: MediaWiki Resource Loader, upsert(), and PostgreSQL: deadlock issues - https://phabricator.wikimedia.org/T222385 [22:21:50] also re: the deadlocks, I just looked at the statements [22:22:03] https://paste.ee/p/85Gyf and this does not make any sense, why is there OR [22:22:22] in WHERE ((md_module = 'skins.minerva.options') OR (md_skin = 'minerva|en-gb')) [22:23:14] with this OR every single upsert updates every single row with "minerva|en-gb" [22:25:30] pretty sure this should be AND judging by other entries... [22:28:45] Is it always MinervaNeue? [22:28:50] no [22:28:53] vector as well [22:29:30] I just did a SELECT * FROM module_deps and everything with en-gb is literally same string for every single entry for a given skin [22:29:40] while old preloaded data for other languages is absolutely fine [22:30:32] currently checking the source; the Database.php upsert() does "if ( count( $uniqueIndexes ) ) {" [22:30:57] and then some logic I do not understand yet [22:31:19] but this given call definitely lists unique indexes [22:31:56] https://paste.ee/p/XWXRy [22:33:04] Reedy: I bet I'm really annoying with these issues but this is literally crashing my server :( [22:33:54] A bug is a bug [22:34:18] The problem is not so many people actually use postgres for mediawiki, so support is limited [22:37:00] yeah [22:37:31] just wondering why it uses OR instead of AND there when it's not even postgresql specific [22:38:54] on mysql, it does something completely different [22:39:20] hmm [22:39:29] where do I even find the difference in code paths? [22:39:33] INSERT INTO ... ON DUPLICATE KEY UPDATE [22:41:03] Reedy: I'm really lost then, because I am looking at resourceloader/ResourceLoaderModule.php [22:41:22] saveFileDependencies calls upsert [22:41:29] Right, but there's no upsert command in mysql [22:41:35] So it's impelemented as above [22:41:42] yes, and the upsert() it calls [22:41:55] goes to, I am guessing, libs/rdbms/database/Database.php [22:42:02] But for mysql it's overridden [22:42:05] which has no PgSQL specific code [22:42:21] oh [22:42:59] wait, so basically it is a bug in the generic code in Database.php? [22:43:24] I know someone made a PostgreSQL upsert() patch for 1.28 [22:43:55] It's possible, upsert isn't that well used across the code [22:44:01] And then adding in pg... [22:44:25] Looks like the code was refactored in 1.28 [22:44:30] What's the patch? [22:45:45] let me find it [22:46:09] Reedy: https://phabricator.wikimedia.org/T167942#4299388 [22:46:57] but the OR is still there [22:47:04] yeah I guess [22:47:04] as it is in database.php [22:47:28] From a quick eyeball, that's what's in Database.php mostly [22:47:36] $clauses[] = $this->makeList( $rowKey, self::LIST_AND ); / $where = [ $this->makeList( $clauses, self::LIST_OR ) ]; [22:47:46] I am guessing the latter overwrites AND with OR [22:48:04] no [22:49:32] I do not quite understand the logic here though [22:49:33] it makes numerous ands (if there's multiple columns), and then ORs them [22:49:42] oh. [22:52:20] so when called with [ 'md_module', 'md_skin' ], is it supposed to OR these? [22:52:59] dunno if it's supposed to, but that's obviously what it's doing [22:56:47] stuffing in dummy values... [22:56:48] string(132) "INSERT INTO `mw_module_deps` (md_module,md_skin,md_deps) VALUES ('skin name','vary','deps') ON DUPLICATE KEY UPDATE md_deps = 'deps'" [22:58:16] basically in 1.29/1.30 postgres support was completely broken in everything that used upsert, not sure about 1.28 [22:58:43] It's possible, yeah [22:59:11] Also, I see another annoyance [23:02:47] Remilia: It kinda looks like it should be using the other column (that it's not using) for the upsert [23:03:10] WHERE ((md_module = 'jquery.makeCollapsible.styles') OR (md_skin = 'vector|en-gb')) [23:03:14] * Reedy looks in his wiki [23:04:04] this should definitely be an AND [23:04:28] this also kind of explains why it updates module_deps all the darn time [23:06:40] I wonder if the call is actually the wrong part [23:06:45] $clauses = []; // list WHERE clauses that each identify a single row [23:07:07] [ 'md_module', 'md_skin' ], [23:07:10] replaced with... [23:07:15] [ [ 'md_module', 'md_skin' ], ], [23:07:40] yes that is what I was thinking about [23:07:47] since it tries to index two arrays [23:08:00] Can you try it to see if it works? [23:08:05] It's a no-op for mysql [23:08:12] I will now [23:11:10] holy [23:11:20] I think this solved it [23:11:46] and RecentChanges no longer times out on load.php under stress but cannot be 100% sure yet [23:11:53] I wonder how many other calls to upsert() are not right [23:12:15] this is the only case I caught in my logs [23:12:27] no deadlock errors yet [23:12:40] It's sparsely used [23:12:50] but... [23:12:52] looking around [23:12:54] a random extension [23:12:55] [ [ 'userid', 'username' ] ], [23:13:11] db connections dropped from 700+ to 2 [23:15:20] 5 minutes without deadlocks [23:15:48] Reedy, if this is really it, you are my saviour [23:16:08] I was bashing my head against the desk with special pages not loading any CSS/JS [23:16:14] under any kind of load [23:22:40] Reedy: the module_deps table is updating like it should now, I am seeing different vector|en-gb entries having different values [23:22:47] yay [23:24:21] time to get php and apache back to normal values instead of 1024 children lol [23:24:27] again, many thanks [23:24:38] I will get it backported to other releases when it's reviewed and merged [23:29:45] * Remilia salutes and flops off to bed as it's 02:29