Page MenuHomePhabricator

Database update for l10n_cache fails on non-EN installs
Closed, ResolvedPublic

Description

Sure, this works when the site language is English, but for other languages, the site has now become out of business, returning HTTP 500, and
$ svn update
At revision 52604.
$ php update.php
A database error has occurred
Query: SELECT lc_value FROM l10n_cache WHERE lc_lang = 'zh-tw' AND lc_key = 'deps' LIMIT 1
Function: LCStore_DB::get
Error: 1146 Table 'transgender.l10n_cache' doesn't exist (mysql...


Version: 1.16.x
Severity: blocker

Details

Reference
bz19447

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:39 PM
bzimport set Reference to bz19447.

my $wgDebugLogFile contains:
Start command line script maintenance/update.php
Main cache: FakeMemCachedClient
Message cache: MediaWikiBagOStuff
Parser cache: MediaWikiBagOStuff
Fully initialised
Unstubbing $wgContLang on call of $wgContLang::ucfirst from Title::secureAndSplit
Class LanguageZh_tw not found; skipped loading
LocalisationCache: using store LCStore_DB
Connecting to mysql.transgender-taiwan.org transgender...
Connected
SQL ERROR: Table 'transgender.l10n_cache' doesn't exist (mysql.transgender-taiwan.org)

Here's the same thing, but when run on an English site. All is well.
Start command line script abj.jidanni.org/maintenance/update.php
Main cache: FakeMemCachedClient
Message cache: MediaWikiBagOStuff
Parser cache: MediaWikiBagOStuff
Fully initialised
Unstubbing $wgContLang on call of $wgContLang::ucfirst from Title::secureAndSplit
LocalisationCache: using store LCStore_DB
Connecting to mysql.transgender-taiwan.org mwabj...
Connected
DatabaseBase::query: Writes done: DESCRIBE ipblocks
SQL ERROR (ignored): Table 'mwabj.profiling' doesn't exist (mysql.transgender-taiwan.org)
SQL ERROR (ignored): Table 'mwabj.l10n_cache' doesn't exist (mysql.transgender-taiwan.org)
Unstubbing $wgAuth on call of $wgAuth::getCanonicalName from User::getCanonicalName
LocalisationCache::isExpired(en): cache missing, need to make one
LocalisationCache::recache: got localisation for en from source

It's a schema change. Always run update.php when updating your installation from SVN.

Oops, didn't read the report properly.

By the way, adding

$ cat StartProfiler.php
require_once( dirname(FILE).'/includes/Profiler.php' );
$wgProfiler = new Profiler;

for the zh-tw case doesn't add any more information to $wgDebugLogFile,
but just proceeds to eat 100% CPU until one hits ^C.

overlordq wrote:

Here's a slightly better backtrace:

Warning: pg_query(): Query failed: ERROR: relation "l10n_cache" does not exist in /var/www/thedarkcitadel.com/wiki/includes/db/DatabasePostgres.php on line 580
A database error has occurred
Query: SELECT lc_value FROM l10n_cache WHERE lc_lang = 'en_gb' AND lc_key = 'deps' LIMIT 1
Function: LCStore_DB::get
Error: 1 ERROR: relation "l10n_cache" does not exist

Backtrace:
#0 /var/www/site.com/wiki/includes/db/Database.php(502): DatabasePostgres->reportQueryError('ERROR: relatio...', 1, 'SELECT lc_valu...', 'LCStore_DB::get', false)
#1 /var/www/site.com/wiki/includes/db/Database.php(838): DatabaseBase->query('SELECT lc_valu...', 'LCStore_DB::get')
#2 /var/www/site.com/wiki/includes/db/Database.php(918): DatabaseBase->select('l10n_cache', Array, Array, 'LCStore_DB::get', Array, Array)
#3 /var/www/site.com/wiki/includes/LocalisationCache.php(690): DatabaseBase->selectRow('l10n_cache', Array, Array, 'LCStore_DB::get')
#4 /var/www/site.com/wiki/includes/LocalisationCache.php(289): LCStore_DB->get('en_gb', 'deps')
#5 /var/www/site.com/wiki/includes/LocalisationCache.php(314): LocalisationCache->isExpired('en_gb')
#6 /var/www/site.com/wiki/includes/LocalisationCache.php(232): LocalisationCache->initLanguage('en_gb')
#7 /var/www/site.com/wiki/includes/LocalisationCache.php(198): LocalisationCache->loadItem('en_gb', 'fallback')
#8 /var/www/site.com/wiki/languages/Language.php(2426): LocalisationCache->getItem('en_gb', 'fallback')
#9 /var/www/site.com/wiki/languages/Language.php(160): Language::getFallbackFor('en_gb')
#10 /var/www/site.com/wiki/languages/Language.php(131): Language::newFromCode('en_gb')
#11 /var/www/site.com/wiki/includes/StubObject.php(122): Language::factory('en_gb')
#12 /var/www/site.com/wiki/includes/StubObject.php(99): StubContLang->_newObject()
#13 /var/www/site.com/wiki/includes/StubObject.php(57): StubObject->_unstub('ucfirst', 5)
#14 /var/www/site.com/wiki/includes/StubObject.php(117): StubObject->_call('ucfirst', Array)
#15 [internal function]: StubContLang->__call('ucfirst', Array)
#16 /var/www/site.com/wiki/includes/Title.php(2341): StubContLang->ucfirst('MediaWiki_datab...')
#17 /var/www/site.com/wiki/includes/Title.php(137): Title->secureAndSplit()
#18 /var/www/site.com/wiki/maintenance/update.php(16): Title::newFromText('MediaWiki datab...')

#19 {main}

overlordq wrote:

Forgot to mention, workaround is to temporarily set your $wgLanguageCode to en, run the update, then switch back.

temporarily set your $wgLanguageCode

Sounds risky.
By the way, for the English case where the new table was successfully added,

$ mysqldump --no-data mwabj|perl -nwle '$h{$_}++ for /CHARSET=\w+/g;END{print "$h{$_}\t$_" for keys %h}'
41 CHARSET=binary
2 CHARSET=utf8
1 CHARSET=latin1

Guess which new table is latin1 :-( . Please ensure new table creation
follows the same rules the other tables were created with.

The core problem here seems to be that before update.php gets to creating the l10n_cache table, it calls Title::newFromText(), which indirectly causes the localization to be loaded from cache. Looks like a tricky problem to solve; a potential fix would be for update.php to disable l10ncache rightaway, if l10ncache allows this and if the offending newFromText() call doesn't happen before that (judging from its argument, I don't think the latter is an issue).

Assigning to Tim, who introduced l10ncache.

(In reply to comment #8)

temporarily set your $wgLanguageCode

Sounds risky.
By the way, for the English case where the new table was successfully added,

$ mysqldump --no-data mwabj|perl -nwle '$h{$_}++ for /CHARSET=\w+/g;END{print "$h{$_}\t$_" for keys %h}'
41 CHARSET=binary
2 CHARSET=utf8
1 CHARSET=latin1

Guess which new table is latin1 :-( . Please ensure new table creation
follows the same rules the other tables were created with.

That should be fixed with r52618

Anybody with $wgLanguageCode!='en' who does
$ svn update
will find their wiki now
*can no longer respond to requests (HTTP 500)
*can no longer run update.php
they only thing they can do is look in the svn manual for how to restore
their wiki to some previous safer revision level, if possible.

(In reply to comment #12)

Anybody with $wgLanguageCode!='en' who does
$ svn update
will find their wiki now
*can no longer respond to requests (HTTP 500)
*can no longer run update.php
they only thing they can do is look in the svn manual for how to restore
their wiki to some previous safer revision level, if possible.

Or use the workaround specified above:

Set $wgLanguageCode to 'en', run update.php, and change it back again.

svn manual for how to restore

$ svn update --revision 52502 #the one before r52503

  • Bug 19491 has been marked as a duplicate of this bug. ***

jodeldi wrote:

seems not to be fixed:

svn update --> succeeded (rev. 52749)

A database error has occurred
Query: SELECT lc_value FROM l10n_cache WHERE lc_lang = 'en' AND lc_key = 'deps' LIMIT 1
Function: LCStore_DB::get
Error: 1146 Table 'wikidb.l10n_cache' doesn't exist (localhost)

svn update --revision 52730 --> succeeded

Query: SELECT lc_value FROM l10n_cache WHERE lc_lang = 'en' AND lc_key = 'deps' LIMIT 1
Function: LCStore_DB::get
Error: 1146 Table 'wikidb.l10n_cache' doesn't exist (localhost)

svn update --revision 52502 --> succeeded

php maintenance/update.php
MediaWiki 1.16alpha Updater
[some output]
Deleting old default messages (this may take a long time!)...Done
Checking site_stats row...ok.
Purging caches...done.
Done.

overlordq wrote:

Works for me. Tried with both en, en_gb, and zh_tw language codes.

MediaWiki 1.16alpha Updater

Going to run database updates for wikidb
Depending on the size of your database this may take a while!
Abort with control-c in the next five seconds... 0
<snip>
... table "user_properties" already exists
... table "log_search" already exists
Creating table "l10n_cache"

... obsolete table "archive2" does not exist

jlerner wrote:

As noted in bug 19491, for me at least, I only ran into the error when running update.php for the very first time. Subsequent runs of update.php, even after manually dropping table l10n_cache, succeeded.

overlordq wrote:

I'd assume the updaters get ran in the order specified in the config, if this assumption is wrong, the follow is false:

do_populate_parent_id get's called in the 1.13 section, but l10n isnt' created until the 1.16 section.

These updaters dont seem to be defined for PG so I simulated by deleting the l10n table, not run update.php but run populateCategory.php first. The backtrace is similar as when running update.php:

A database error has occurred
Query: SELECT lc_value FROM l10n_cache WHERE lc_lang = 'en' AND lc_key = 'deps' LIMIT 1
Function: LCStore_DB::get
Error: 1 ERROR: relation "l10n_cache" does not exist

Backtrace:
#0 /var/www/mysite.com/wiki/includes/db/Database.php(502): DatabasePostgres->reportQueryError('ERROR: relatio...', 1, 'SELECT lc_valu...', 'LCStore_DB::get', false)
#1 /var/www/mysite.com/wiki/includes/db/Database.php(838): DatabaseBase->query('SELECT lc_valu...', 'LCStore_DB::get')
#2 /var/www/mysite.com/wiki/includes/db/Database.php(918): DatabaseBase->select('l10n_cache', Array, Array, 'LCStore_DB::get', Array, Array)
#3 /var/www/mysite.com/wiki/includes/LocalisationCache.php(725): DatabaseBase->selectRow('l10n_cache', Array, Array, 'LCStore_DB::get')
#4 /var/www/mysite.com/wiki/includes/LocalisationCache.php(299): LCStore_DB->get('en', 'deps')
#5 /var/www/mysite.com/wiki/includes/LocalisationCache.php(324): LocalisationCache->isExpired('en')
#6 /var/www/mysite.com/wiki/includes/LocalisationCache.php(242): LocalisationCache->initLanguage('en')
#7 /var/www/mysite.com/wiki/includes/LocalisationCache.php(205): LocalisationCache->loadItem('en', 'namespaceNames')
#8 /var/www/mysite.com/wiki/languages/Language.php(241): LocalisationCache->getItem('en', 'namespaceNames')
#9 /var/www/mysite.com/wiki/languages/Language.php(289): Language->getNamespaces()
#10 [internal function]: Language->getNsText(14)
#11 /var/www/mysite.com/wiki/includes/StubObject.php(58): call_user_func_array(Array, Array)
#12 /var/www/mysite.com/wiki/includes/StubObject.php(117): StubObject->_call('getNsText', Array)
#13 [internal function]: StubContLang->__call('getNsText', Array)
#14 /var/www/mysite.com/wiki/includes/Title.php(470): StubContLang->getNsText(14)
#15 /var/www/mysite.com/wiki/includes/Title.php(277): Title::makeName(14, 'Main_Pages', '')
#16 /var/www/mysite.com/wiki/includes/Category.php(88): Title::makeTitleSafe(14, 'Main_Pages')
#17 /var/www/mysite.com/wiki/maintenance/populateCategory.inc(57): Category::newFromName('Main_Pages')
#18 /var/www/mysite.com/wiki/maintenance/populateCategory.php(53): populateCategory('', 10, 0, 1)

#19 {main}

(In reply to comment #17)

seems not to be fixed:

svn update --> succeeded (rev. 52749)

A database error has occurred
Query: SELECT lc_value FROM l10n_cache WHERE lc_lang = 'en' AND lc_key =
'deps' LIMIT 1
Function: LCStore_DB::get
Error: 1146 Table 'wikidb.l10n_cache' doesn't exist (localhost)

svn update --revision 52730 --> succeeded

Query: SELECT lc_value FROM l10n_cache WHERE lc_lang = 'en' AND lc_key =
'deps' LIMIT 1
Function: LCStore_DB::get
Error: 1146 Table 'wikidb.l10n_cache' doesn't exist (localhost)

svn update --revision 52502 --> succeeded

Are you saying you get an error from the wiki after you do an svn update, but before you run maintenance/update.php?

php maintenance/update.php
MediaWiki 1.16alpha Updater
[some output]
Deleting old default messages (this may take a long time!)...Done
Checking site_stats row...ok.
Purging caches...done.
Done.

This is the output you would expect when the bug is fixed, maintenance/update.php does not get this far when it fails.

(In reply to comment #20)

I'd assume the updaters get ran in the order specified in the config, if this
assumption is wrong, the follow is false:

do_populate_parent_id get's called in the 1.13 section, but l10n isnt' created
until the 1.16 section.

These updaters dont seem to be defined for PG so I simulated by deleting the
l10n table, not run update.php but run populateCategory.php first. The
backtrace is similar as when running update.php:

That does not simulate anything. Only maintenance/update.php and config/index.php will work before the l10n_cache table is created. The rest of the maintenance scripts and the wiki itself will fail. That is not a bug.

jodeldi wrote:

my four steps to become a irrespondable wiki:

  1. svn up
  1. wiki not respondable, error:

Database error
A database error has occurred
Query: SELECT lc_value FROM l10n_cache WHERE lc_lang = 'de' AND lc_key = 'deps' LIMIT 1
Function: LCStore_DB::get
Error: 1146 Table 'wikidb.l10n_cache' doesn't exist (localhost)

  1. $wgLanguageCode = "en" (suggested above, config is normaly "de", but result is the same as with "en")
  1. php maintenance/update.php, error:

A database error has occurred
Query: SELECT lc_value FROM l10n_cache WHERE lc_lang = 'en' AND lc_key = 'deps' LIMIT 1
Function: LCStore_DB::get
Error: 1146 Table 'wikidb.l10n_cache' doesn't exist (localhost)

Only svn up --revision 52502 will fix these

(In reply to comment #22)
Everything's working fine for me now at revision level

$ GET 'http://radioscanningtw.jidanni.org/api.php?action=expandtemplates&text={{CURRENTVERSION}}&format=yaml'

expandtemplates:

*: 1.16alpha(r52770)

(In reply to comment #19)

As noted in bug 19491, for me at least, I only ran into the error when running
update.php for the very first time. Subsequent runs of update.php, even after
manually dropping table l10n_cache, succeeded.

That's expected. You can recover your error by dropping l10n_cache, and also doing:

DELETE FROM updatelog WHERE ul_key='populate category';

The wiki has to have at least one category to trigger the error, and it needs to use a language code with its own class to avoid the error from Language::factory() reported by Jidanni. It's fixed by r52730.

thomasV1 wrote:

I have the same problem after updating at revision r52836
update.php fails with the following message :

A database error has occurred
Query: SELECT lc_value FROM l10n_cache WHERE lc_lang = 'en' AND lc_key = 'deps' LIMIT 1
Function: LCStore_DB::get
Error: 1146 Table 'wikidb.l10n_cache' doesn't exist (localhost)

it works if I create the table manually

(In reply to comment #25)

I have the same problem after updating at revision r52836
update.php fails with the following message :

A database error has occurred
Query: SELECT lc_value FROM l10n_cache WHERE lc_lang = 'en' AND lc_key =
'deps' LIMIT 1
Function: LCStore_DB::get
Error: 1146 Table 'wikidb.l10n_cache' doesn't exist (localhost)

it works if I create the table manually

Can you get a backtrace please? Just comment out the whole of DBQueryError::getText(). So includes/db/Database.php around line 2559 becomes:

/**** REMOVED TO GET BACKTRACE
function getText() {
if ( $this->useMessageCache() ) {

		return wfMsg( 'dberrortextcl', htmlspecialchars( $this->getSQL() ),
		  htmlspecialchars( $this->fname ), $this->errno, htmlspecialchars( $this->error ) ) . "\n";

} else {

		return $this->getMessage();

}
}
****/

I've tested an upgrade from a fresh install of 1.15, but it's possible that there are problematic extensions that invoke the localisation cache before it's disabled.

thomasV1 wrote:

here it is :

A database error has occurred
Query: SELECT lc_value FROM l10n_cache WHERE lc_lang = 'en' AND lc_key = 'deps' LIMIT 1
Function: LCStore_DB::get
Error: 1146 Table 'wikidb.l10n_cache' doesn't exist (localhost)

Backtrace:
#0 /var/www/w/includes/db/Database.php(502): DatabaseBase->reportQueryError('Table 'wikidb.l...', 1146, 'SELECT lc_valu...', 'LCStore_DB::get', false)
#1 /var/www/w/includes/db/Database.php(838): DatabaseBase->query('SELECT lc_valu...', 'LCStore_DB::get')
#2 /var/www/w/includes/db/Database.php(918): DatabaseBase->select('l10n_cache', Array, Array, 'LCStore_DB::get', Array, Array)
#3 /var/www/w/includes/LocalisationCache.php(725): DatabaseBase->selectRow('l10n_cache', Array, Array, 'LCStore_DB::get')
#4 /var/www/w/includes/LocalisationCache.php(299): LCStore_DB->get('en', 'deps')
#5 /var/www/w/includes/LocalisationCache.php(324): LocalisationCache->isExpired('en')
#6 /var/www/w/includes/LocalisationCache.php(275): LocalisationCache->initLanguage('en')
#7 /var/www/w/includes/LocalisationCache.php(230): LocalisationCache->loadSubitem('en', 'messages', 'proofreadpage_n...')
#8 /var/www/w/languages/Language.php(1462): LocalisationCache->getSubitem('en', 'messages', 'proofreadpage_n...')
#9 /var/www/w/includes/MessageCache.php(531): Language->getMessage('proofreadpage_n...')
#10 [internal function]: MessageCache->get('proofreadpage_n...', true, true)
#11 /var/www/w/includes/StubObject.php(58): call_user_func_array(Array, Array)
#12 /var/www/w/includes/StubObject.php(76): StubObject->_call('get', Array)
#13 [internal function]: StubObject->__call('get', Array)
#14 /var/www/w/includes/GlobalFunctions.php(646): StubObject->get('proofreadpage_n...', true, true)
#15 /var/www/w/includes/GlobalFunctions.php(611): wfMsgGetKey('proofreadpage_n...', true, true, true)
#16 /var/www/w/includes/GlobalFunctions.php(559): wfMsgReal('proofreadpage_n...', Array, true, true)
#17 /var/www/w/extensions/ProofreadPage/ProofreadPage.php(74): wfMsgForContent('proofreadpage_n...')
#18 [internal function]: pr_main()
#19 /var/www/w/includes/Setup.php(328): call_user_func('pr_main')
#20 /var/www/w/maintenance/commandLine.inc(259): require_once('/var/www/w/incl...')
#21 /var/www/w/maintenance/update.php(14): require('/var/www/w/main...')
#22 {main}

It looks like the initialization pr_main() of extensions/ProofreadPage should not invoke wfMsgForContent. I did this in order to store the names of the "page" and "index" namespaces as globals, because they are frequently needed by the extension. I suppose this was not the right way to do it, but I do not know how to fix it..

It looks like the ProofreadPage bug was fixed by r53040. Reclosing.

kwi wrote:

I can confirm that other extensions may also cause this problem. :-)

(In my case, it was DynamicPageList. One of the forks, anyway. The names of those are confusing enough that I'm no longer quite sure which one we're running...)

Since it's not immediately clear from the above discussion, I'd like to add:

*The generic work-around for this problem is to disable all extensions while running update.php.*

overlordq wrote:

Please open new bugs for different issues and not change old unrelated bugs.