On 04/04/12 20:44, [[w:en:User:Madman]] wrote:
On Fri, Mar 30, 2012 at 7:05 PM, Platonides
<platonides(a)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.