Last modified: 2012-08-04 20:48:42 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 26612 - [Installer] Regression: Postgres cannot install
[Installer] Regression: Postgres cannot install
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Database (Other open bugs)
1.17.x
All All
: High blocker (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: postgres 26676 28179
  Show dependency treegraph
 
Reported: 2011-01-06 20:32 UTC by Chad H.
Modified: 2012-08-04 20:48 UTC (History)
6 users (show)

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


Attachments

Description Chad H. 2011-01-06 20:32:31 UTC
I'm aware this regression is a result of the massive refactoring I and others have done for new-installer.

However, I need help from the postgres guys on moving DatabasePostgres::initial_setup() to the new-installer format (using callbacks similar to MysqlInstaller's setupUser). As best I can tell, this function does a few major things (and is called twice):
* Uses the superuser to create the less-privileged user that will access the database (this should copy MySQL's setupUser, although maybe at a different stage)
* Creates the database/schema and assigns the user (PostgresInstaller::setupDatabase() should be updated to include this)
* Sets up ts2 if needed (am I correct in remembering this is old and probably won't be needed much longer?)
* Setup Plpgsql if needed
* A few other minor tweaks (date format, timezone, etc)

These steps should be split out into functions in PostgresInstaller and added as callbacks to the correct stops in the install steps.

I didn't assign this to anyone, but this should be considered a blocker to the 1.17 release. CC'd Postgres guys and Mark H.
Comment 2 OverlordQ 2011-01-07 07:28:56 UTC
If you have specific "How do I do <foo>" questions I'd be more then willing to answer. I'd just rather not have to trace the myriad of function calls and new templating thats done.
Comment 3 Chad H. 2011-01-07 18:27:47 UTC
That myriad of function calls is way clearer than the bowl of mush sitting in DatabasePostgres.

Suit yourself, I suppose. Needs review: r79828.
Comment 4 Chad H. 2011-01-10 19:19:47 UTC
Also r79950.
Comment 5 Rob Lanphier 2011-01-11 23:02:07 UTC
Changing dependency from bug 26611 to bug 26676.  We don't need to fix this for deployment, but we do need to fix this before releasing the tarball
Comment 6 Tim Starling 2011-01-27 02:33:19 UTC
One problem is that DatabaseBase::selectDB() does not work for SQLite or PostgreSQL, so it should not be used in DBMS-independent code. In particular, needsUpgrade() is broken because it depends on selectDB() returning false if the database does not exist. I think PostgresqlInstaller should check for the existence of the database by attempting to connect to it with the administrative credentials, and checking the resulting error message for "FATAL:  database "..." does not exist".

There's no guarantee that the administrative user will be able to connect to the template1 database, or any other specific database, so you can't use the pg_database catalog. If the database doesn't exist, I think it's fair to assume that you need to be able to connect to the "postgres" administrative database in order to create one.

The old installer relied on creation of a special user to ensure that the session settings were correct:

$SQL = "ALTER USER $safeuser SET timezone = 'GMT'";
$SQL = "ALTER USER $safeuser SET datestyle = 'ISO, YMD'";

This is missing from the new installer, which is good, but DatabasePostgres::open() should make sure the correct settings are set in the session.

Dropping support for full text search before PostgreSQL 8.3 (released 2008) would allow the setup code to be substantially simpler. The "schema for tsearch2" ($wgDBts2schema) setting could be dropped, currently it does nothing in PostgreSQL 8.3 or later. SearchPostgres.php would be slightly simpler.
Comment 7 Chad H. 2011-02-23 16:06:50 UTC
See trunk as of r82674.

All of the $wgDBuser-specific settings have been cleaned up and are taken care of in open() and the pre-8.3 compat stuff has been dropped. I implemented a form of selectDB() (which works how you'd expect really) which resolves the upgrade issue. 

Haven't handled the "admin user might not be able to use pg_catalog, much less template1" case yet.
Comment 8 Greg Sabino Mullane 2011-03-21 22:34:04 UTC
I've got the installer in a working form now, although I've not tested any corner cases or given it extensive testing. If someone does find something, please open a new bug of course, and cc me.
Comment 9 Mark A. Hershberger 2011-03-22 05:09:01 UTC
closing per last comment

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


Navigation
Links