Last modified: 2012-08-04 20:49:00 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.
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}
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 );
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)
r88936
Reopening since the proposed fix was reverted.
I never saw it while I was testing r89821, so it's probably fixed. Please test the version in Subversion REL1_17.
Likewise, I didn't see it. Closing. Greg, if you see still see this, let us know ASAP.
Still happens on HEAD
#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}
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.
If someone can provide a reliable reproduction procedure on PostgreSQL or SQLite, then we can take it from there.
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
Remarking as RESOLVED FIX
