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.

> 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.

(Also, please note that I'm putting at least public work on Dementia
on hold for a little bit, as my full-time job has just been insane
lately and I don't have the time to dedicate to it and its potential
users that it deserves.)

-Madman

_______________________________________________
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

Reply via email to