Last modified: 2009-12-06 14:49:24 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...
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.
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} ====
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.
Tweak summary.
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
Fixed in r52730.
*** Bug 19491 has been marked as a duplicate of this bug. ***
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.
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 ====
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.
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.
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
(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.
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.
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.
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.*
Please open new bugs for different issues and not change old unrelated bugs.
