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.
Version: 1.20.x
Severity: enhancement
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.
Version: 1.20.x
Severity: enhancement
Status | Subtype | Assigned | Task | |
---|---|---|---|---|
· · · | ||||
Invalid | None | T2384 [REPLACED BY TAG] PostgreSQL/pgsql support (tracking) | ||
Resolved | None | T28676 Milestone: MediaWiki 1.17 release tarball (tracking) | ||
Resolved | None | T30172 wfGetDB called when it shouldn't be | ||
· · · |
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)
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.
overlordq wrote:
#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}
sumanah wrote:
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.
overlordq wrote:
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.
Hypothesis, if the tables exist we're forgetting to re-enable the lb?
So comparing DatabaseInstaller and PostgresInstaller, lets try r101880