Last modified: 2012-08-04 20:49:00 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 28172 - wfGetDB called when it shouldn't be
wfGetDB called when it shouldn't be
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Installer (Other open bugs)
1.20.x
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: postgres 26676
  Show dependency treegraph
 
Reported: 2011-03-21 22:12 UTC by Greg Sabino Mullane
Modified: 2012-08-04 20:49 UTC (History)
6 users (show)

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


Attachments

Description Greg Sabino Mullane 2011-03-21 22:12:58 UTC
Seen at one of the final steps:

"
Creating administrator user account...
Mediawiki tried to access the database via wfGetDB(). This is not allowed.
"

Not sure yet if strictly Postgres related.
Comment 1 Greg Sabino Mullane 2011-03-21 22:18:41 UTC
Backtrace:

#0 /var/www/gtsm.com/p3/includes/GlobalFunctions.php(2943): LBFactory_Fake->getMainLB(false)
#1 /var/www/gtsm.com/p3/includes/GlobalFunctions.php(2933): wfGetLB(false)
#2 /var/www/gtsm.com/p3/includes/User.php(2636): wfGetDB(-1)
#3 /var/www/gtsm.com/p3/includes/installer/Installer.php(1383): User->idForName()
#4 [internal function]: Installer->createSysop(Object(PostgresInstaller))
#5 /var/www/gtsm.com/p3/includes/installer/Installer.php(1293): call_user_func(Array, Object(PostgresInstaller))
#6 /var/www/gtsm.com/p3/includes/installer/WebInstallerPage.php(1058): Installer->performInstallation(Array, Array)
#7 /var/www/gtsm.com/p3/includes/installer/WebInstaller.php(244): WebInstaller_Install->execute()
#8 /var/www/gtsm.com/p3/mw-config/index.php(46): WebInstaller->execute(Array)
#9 /var/www/gtsm.com/p3/mw-config/index.php(14): wfInstallerMain()
#10 {main}
Comment 2 Greg Sabino Mullane 2011-03-21 22:25:57 UTC
So it looks like Installer.php tells the loadbalancer to go away @ line 311 in __construct:

LBFactory::disableBackend();

But then we make our way to User.php, which @ line 2636 calls it inside of idForName():

$dbr = wfGetDB( DB_SLAVE );
Comment 3 Chad H. 2011-03-21 22:35:04 UTC
I'll take a look at this, the order of operations here matters quite a bit (and can easily break for MySQL, SQLite, etc etc too)
Comment 4 Mark A. Hershberger 2011-05-26 21:49:54 UTC
r88936
Comment 5 Tim Starling 2011-06-09 05:51:29 UTC
Reopening since the proposed fix was reverted.
Comment 6 Tim Starling 2011-06-10 13:00:11 UTC
I never saw it while I was testing r89821, so it's probably fixed. Please test the version in Subversion REL1_17.
Comment 7 Mark A. Hershberger 2011-06-12 18:58:16 UTC
Likewise, I didn't see it.  Closing.

Greg, if you see still see this, let us know ASAP.
Comment 8 OverlordQ 2011-10-31 19:59:25 UTC
Still happens on HEAD
Comment 9 OverlordQ 2011-10-31 20:00:20 UTC
#0 /var/www/thedarkcitadel.com/w/includes/GlobalFunctions.php(3178): LBFactory_Fake->getMainLB(false)
#1 /var/www/thedarkcitadel.com/w/includes/GlobalFunctions.php(3168): wfGetLB(false)
#2 /var/www/thedarkcitadel.com/w/includes/User.php(2858): wfGetDB(-1)
#3 /var/www/thedarkcitadel.com/w/includes/installer/Installer.php(1441): User->idForName()
#4 [internal function]: Installer->createSysop(Object(PostgresInstaller))
#5 /var/www/thedarkcitadel.com/w/includes/installer/Installer.php(1355): call_user_func(Array, Object(PostgresInstaller))
#6 /var/www/thedarkcitadel.com/w/includes/installer/WebInstallerPage.php(1133): Installer->performInstallation(Array, Array)
#7 /var/www/thedarkcitadel.com/w/includes/installer/WebInstaller.php(254): WebInstaller_Install->execute()
#8 /var/www/thedarkcitadel.com/w/mw-config/index.php(50): WebInstaller->execute(Array)
#9 /var/www/thedarkcitadel.com/w/mw-config/index.php(18): wfInstallerMain()
#10 {main}
Comment 10 Sumana Harihareswara 2011-11-02 22:07:33 UTC
Tim, can you offer some wisdom or guidance here?  This bug is hard to reproduce -- Greg Sabino Mullane and OverlordQ can repro it, but Chad can't reproduce it on MySQL or on SQLite -- and "it shouldn't differ by dbms, since that code is shared."

DJ Bauch offered, "I see this  (Bug 28172)  happen when an install fails to complete for some reason (on SQL Server in my case) and then tries to resume. Restarting the install from scratch after fixing whatever caused the failure works around the problem that the load balancer has been turned off and never turned back on."

Selected IRC conversation:

    <G_SabinoMullane> I think the key is here: #2 /var/www/thedarkcitadel.com/w/includes/User.php(2858): wfGetDB(-1)
    <^demon> After the db has been initialized the LB is re-enabled.
    <^demon> And then User can do its thing.
    <G_SabinoMullane> ^demon: Why is the LB being disabled there?
    <MaxSem> e.g. to prevent you from creating a user when you shouldn't :)
    <^demon> The LB code automatically does things like connect to the database and such.
    <MaxSem> =when DB is not ready yet
    <^demon> Right, it's to keep you from breaking things accidentally.
Comment 11 Tim Starling 2011-11-02 22:25:31 UTC
If someone can provide a reliable reproduction procedure on PostgreSQL or SQLite, then we can take it from there.
Comment 12 OverlordQ 2011-11-03 21:00:42 UTC
The way I caught it was because when the _sha1 fields were re-added Pg wasn't included in the schema change so when the installer got to adding the first revision of the main page it died because rev_sha1 didn't exist. So I added it to tables.sql. Fuzzy on the next steps but pretty sure I did the following, but I'm pretty sure I hit the back button below the error, fixed the tables.sql, then clicked continue button.


1) comment out rev_sha1 in maintenance/postgres/tables.sql
2) Continue through install process
3) Receive error
4) Click back button on bottom of page
5) Correct SQL issues
6) Click continue on bottom of page
8) Click continue on confirmation page
9) Receive error.

--
    Setting up database... done
    Checking for language PL/pgSQL... done
    Creating schema... done
    Creating tables... done
    Information

    Warning: MediaWiki tables seem to already exist. Skipping creation.
    Populating default interwiki table... done
    Information

    Warning: The interwiki table seems to already have entries. Skipping default list.
    Committing changes... done
    Initializing statistics... done
    Generating secret keys... done
    Creating administrator user account...

    Mediawiki tried to access the database via wfGetDB(). This is not allowed.

    Backtrace:
--


Hypothesis, if the tables exist we're forgetting to re-enable the lb?

So comparing DatabaseInstaller and PostgresInstaller, lets try r101880
Comment 13 OverlordQ 2011-11-20 23:30:51 UTC
Remarking as RESOLVED FIX

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


Navigation
Links