Last modified: 2009-12-06 14:49:24 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T21447, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 19447 - Database update for l10n_cache fails on non-EN installs
Database update for l10n_cache fails on non-EN installs
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Database (Other open bugs)
1.16.x
All All
: Normal blocker (vote)
: ---
Assigned To: Tim Starling
:
: 19491 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-30 18:09 UTC by Dan Jacobson
Modified: 2009-12-06 14:49 UTC (History)
10 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Dan Jacobson 2009-06-30 18:09:38 UTC
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...
Comment 1 Dan Jacobson 2009-06-30 18:49:03 UTC
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)
Comment 2 Dan Jacobson 2009-06-30 19:02:13 UTC
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
Comment 3 Andrew Garrett 2009-06-30 19:04:44 UTC
It's a schema change. Always run update.php when updating your installation from SVN.
Comment 4 Andrew Garrett 2009-06-30 19:07:35 UTC
Oops, didn't read the report properly.
Comment 5 Dan Jacobson 2009-06-30 20:11:34 UTC
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.
Comment 6 OverlordQ 2009-06-30 20:33:24 UTC
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}
====
Comment 7 OverlordQ 2009-06-30 20:38:24 UTC
Forgot to mention, workaround is to temporarily set your $wgLanguageCode to en, run the update, then switch back.
Comment 8 Dan Jacobson 2009-06-30 20:43:52 UTC
>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.
Comment 9 Chad H. 2009-06-30 23:45:43 UTC
Tweak summary.
Comment 10 Roan Kattouw 2009-07-01 14:13:06 UTC
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.
Comment 11 Chad H. 2009-07-01 14:15:55 UTC
(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
Comment 12 Dan Jacobson 2009-07-02 10:26:50 UTC
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.
Comment 13 Andrew Garrett 2009-07-02 10:30:55 UTC
(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.
Comment 14 Dan Jacobson 2009-07-02 11:04:05 UTC
> svn manual for how to restore
$ svn update --revision 52502 #the one before r52503
Comment 15 Tim Starling 2009-07-03 06:57:05 UTC
Fixed in r52730.
Comment 16 Roan Kattouw 2009-07-03 09:33:59 UTC
*** Bug 19491 has been marked as a duplicate of this bug. ***
Comment 17 Martin Seidel 2009-07-03 18:09:20 UTC
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.
Comment 18 OverlordQ 2009-07-03 19:23:08 UTC
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
====
Comment 19 Joshua C. Lerner 2009-07-03 19:27:57 UTC
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.
Comment 20 OverlordQ 2009-07-03 19:50:01 UTC
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}
===
Comment 21 Tim Starling 2009-07-04 00:10:37 UTC
(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.

Comment 22 Martin Seidel 2009-07-04 12:26:21 UTC
my four steps to become a irrespondable wiki:

1. svn up

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

2. $wgLanguageCode = "en" (suggested above, config is normaly "de", but result is the same as with "en")

4. 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
Comment 23 Dan Jacobson 2009-07-04 22:51:48 UTC
(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)
Comment 24 Tim Starling 2009-07-05 03:40:01 UTC
(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.
Comment 25 ThomasV 2009-07-07 15:51:19 UTC
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
Comment 26 Tim Starling 2009-07-08 10:49:25 UTC
(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.
Comment 27 ThomasV 2009-07-08 12:41:07 UTC
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..
Comment 28 Tim Starling 2009-07-22 04:10:18 UTC
It looks like the ProofreadPage bug was fixed by r53040. Reclosing.
Comment 29 Søren Løvborg 2009-07-22 19:49:10 UTC
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.*
Comment 30 OverlordQ 2009-12-06 14:49:24 UTC
Please open new bugs for different issues and not change old unrelated bugs.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links