Run updateRestrictions.php on WMF cluster to migrate page_restrictions column to page_restrictions table.
Description
Description
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Invalid | None | T51188 [DO NOT USE] Schema changes for Wikimedia wikis (tracking) [superseded by #Blocked-on-schema-change] | ||
| Open | None | T60674 Drop page.page_restrictions column from Wikimedia wikis | ||
| Open | None | T30751 prop=info&inprop=protection sometimes shows protection multiple times | ||
| Stalled | None | T35334 Remove database column page.page_restrictions from MediaWiki core | ||
| Open | None | T218446 Remove use of legacy page.page_restrictions field | ||
| Resolved | Reedy | T166184 Run updateRestrictions.php on WMF wikis |
Event Timeline
Comment Actions
Hi,
We (DBAs) assume this is just a heads up for us right? We do appreciate it! :-)
If you don't mind, once you are ready to run it, please update https://wikitech.wikimedia.org/wiki/Deployments so everyone is aware.
Thanks!
Comment Actions
Should just be a jfdi one this.
enwiki has 4109... I can't imagine many wikis having many more rows to run
Comment Actions
Mentioned in SAL (#wikimedia-operations) [2017-07-19T12:40:12Z] <Reedy> running foreachwiki updateRestrictions.php T166184
Comment Actions
42634455 pages on enwiki, 4109 page_restrictions != "" pages.
Batch increased ten fold in https://gerrit.wikimedia.org/r/366289
TBH, I think the code should just be doing just be doing a where page_restrictions != "" and a limit of the batch size
Script is pretty slow, and I can't really see any reason for it to be quite so conservative.
It's somewhere halfway through enwiki, but it's been running for 5 hours :(