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.

overlordq wrote:

Still happens on HEAD

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.

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
7. Click continue on confirmation page
8. 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

overlordq wrote:

Remarking as RESOLVED FIX

Migrating from the old tracking task to a tag for PostgreSQL-related tasks.