On 04/04/12 20:44, [[w:en:User:Madman]] wrote:
On Fri, Mar 30, 2012 at 7:05 PM, Platonides platonides@gmail.com wrote:
$wgReadOnly no longer means "don't write to the db ever", but if it gives problems with a ro db, maybe we could fix it somewhere so you don't need to patch it.
I do understand $wgReadOnly means MediaWiki may still write to the database, per the documentation; perhaps, though, an error from MySQL that the server's running with --read-only (which was the case when I tested) shouldn't be fatal, at least not to a list=blocks request.
Interesting. Can you provide a simple test case? (eg. block this, restart mysql ro, visit this url).
Also, can you provide the MediaWiki patches you needed? I took a look at your home, but didn't see it.
I think they are there, in the underlying tables. It's just not that we can't view or use them from the views, which is what we access to. It's a pity, when we know the optimum SQL queries using force index, but I see the point of the approach, as they could be abused in tables with only partial columns shown, and private ones covered by the indexes.
The indexes I've verified we don't have that would be forced are oi_name_timestamp, rc_timestamp, pl_namespace, page_random, el_index, name_title, cl_sortkey, times, and usertext_timestamp. I can't imagine almost any of these are for privacy reasons, so I just assumed it was for performance reasons.
We are working from views, the indexes are in the tables.