On 04/04/12 20:44, [[w:en:User:Madman]] wrote: > On Fri, Mar 30, 2012 at 7:05 PM, Platonides <[email protected]> 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. _______________________________________________ Toolserver-l mailing list ([email protected]) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
