PostgresUpdater fails on PostgreSQL 8.3.14:
> Changing 'image.img_metadata' default value
> A database query syntax error has occurred.
> The last attempted database query was:
> "ALTER TABLE image ALTER img_metadata SET DEFAULT '\x'::bytea"
> from within function "".
> Database returned error "22P02: ERROR: invalid input syntax for type
> bytea"
Patchset 2:
> Database returned error "42883: ERROR: function
> generate_subscripts(int2vector, integer) does not exist
> LINE 7: (SELECT generate_subscripts(isub.indkey, 1) AS g
> ^
> HINT: No function matches the given name and argument types. You
> might need to add explicit type casts.
> "
Change-Id: I6e1811ded0eedad9c0eb0df715698c45aaf8e3f0
Changeset 1 of https://gerrit.wikimedia.org/r/#change,3365:
763b57f9f2af131a2d8e65f520a23c00109be0e1
got mis-merged in changeset 2:
f752cf8042
And introduced into master wth
0a792a1dcb
Also, marking all new functions as @since 1.19
since we want to have them there later.
Patchset 2: whitespace fixes
Patchset 3: Fix <?php
Patchset 4: rebase to current master
Change-Id: Ic7d940dfec8890de20197128505962375fac4f06
Bug 35572 - Blocks appear to succeed even if query fails due to wrong DB
structure
When emulating INSERT IGNORE ignore only SQL Error Code 23505
- unique key violation
http://www.postgresql.org/docs/9.1/interactive/errcodes-appendix.html
All other error codes (missing column, syntex error, whatever)
should unconditionally abort the transaction and show internal
error to the user.
Patchset 2: Fixed whitespace.
Patchset 3: More whitespace. And ()'s.
Patchset 4: Yet more whitespace.
Patchset 5: rebase & fix conflict in release-notes
Change-Id: Ic32bff9fff46bce124273156d224fa01b8adc008
* PostgresField now reports column default value
* DatabasePostgres::indexAttributes reports index
details
* Perform schema update in one transaction
With this change we can sucessfully update
MediaWiki 1.7.3 schema to trunk^Wmaster
Patch set 2: Rebased against master. PLEASE check carefully
to make sure I got those conflicted files right.
Conflicts:
includes/db/DatabasePostgres.php
includes/installer/PostgresUpdater.php
Change-Id: Iebb6855e8f6f44470bbb1dc5ab9ac1abb513adfe
Upgrade to 1.19 on Postgres fails due to incomplete query when trying to
defer foreign key for externallinks
* FieldInfo::conname() should return NULL not "" when constraint
is not present
* Re-create missing constraint on schema update
Change-Id: I7ca351e07d228afdf4a5c3bef365f42a27c9ac45
Follow-up to r15791.
You can lie to me, but not to your installer.
Make DatabasePostgres::tableExists to check for real table names, not
faked ones.
DatabasePostgres is currently lying to the rest of the MediaWiki that
"mwuser" table is actually called "user" and that "pagecontents" is
called "text". While MediaWiki does not care, the installer (and updater
do).
This allows us to overcome first hurdle in getting MediaWiki 1.7.3 to
update to trunk on PostgreSQL and uncover further bugs.
For this commit to actually do something, we rename those tables when
upgrading to match what we have in maintenance/postgres/tables.sql
And by the way, tell installer not to check for "user" table, since most
PostgreSQL users will have "mwuser" instead. Picking "archive" instead.
Patchset2: wrapped commit message at 72 chars
Change-Id: Ic874e92bb1adda3430d3292423d4f3617c25456c
You can lie to me, but not to your installer.
Make DatabasePostgres::tableExists to check
for real table names, not faked ones.
DatabasePostgres is currently lying to the rest
of the MediaWiki that "mwuser" table is actually
called "user" and that "pagecontents" is called
"text". While MediaWiki does not care, the
installer (and updater do).
This allows us to overcome first hurdle
in getting MediaWiki 1.7.3 to update to trunk
on PostgreSQL and uncover further bugs.
For this commit to actually do something,
we rename those tables when upgrading to match
what we have in maintenance/postgres/tables.sql
And by the way, tell installer not to check
for "user" table, since most PostgreSQL users
will have "mwuser" instead. Picking "archive"
instead.
[exec] PHP Fatal error: Call to a member function getCoreSchema() on a non-object in /var/lib/jenkins/jobs/MediaWiki-postgres-phpunit/workspace/mw-core/includes/db/DatabasePostgres.php on line 216
* Introduce $wgDebugDBTransactions facility to help
figure out what's going on with transactions.
Currently PostgreSQL only.
PostgresTransactionState can be easily be made more general
to trace all sorts of state machinery.
* Improve r113408: we don't need to full reconnect on error,
rollback is enough.
Rolling back breaks search_path, as PostgreSQL
can manage sessions settings under transaction therefore
we need to improve schema sniffing introduced in r82674
* Introduce few schema handling functions. This could
probably be generalized for other databases like DB2 and Oracle.
* Fix bug 15816 - Add a switch for SETting the search_path
We try to avoid touching search_path at all unless
really necessary. Even in this case we append MediaWiki
core schema to the front of the list.
* No longer add $wgDBmwschema to PostgreSQL role search_path
in the installer. This is no longer necessary as
setting schema on connect should ReallyWorkNow(tm).
* Get rid as much as possible of $wgDBmwschema and
bring us one step closer to fix bug 16794 (wgSharedDB
support).
All references to core MediaWiki schema in PostgreSQL
specific code should now use Database::getCoreSchema()
unless we know what we are doing.
Followup-To: r113408 r82674
After a query error, PostgreSQL transaction is aborted
until it's terminated or the query is closed.
All further queries result in:
ERROR: current transaction is aborted, commands ignored
until end of transaction block
Those subsequent errors are ignored by double fault handling in
DatabaseBase::reportQueryError but they cause all localization
of error messages to fail (unable to issue queries to message
tables) and errors lke
This resulted in a broken MediaWiki screen with
<databaseerror>
<dberrortext>
instead of localized error message.
We need to fully reset database connection because after
pg_connection_reset() various session parameters need to
be set again (like "search_path"), otherwise tables will not be
found.
ERROR: relation "msg_resource" does not exist
ERROR: relation "l10n_cache" does not exist
This is reverting the work done by MaxSem to support stored procedures
and stored function in MySQL. The reasons are:
- it is not needed yet
- tests are not functionals
- alter the stable include/db/Database.php and drop support for ';;'
So please create a branch to work on it and merge it back in trunk
once we have branched 1.19 :-)
I have opened bug 33654 to track this enhancement request.
Reverts r107376, r107994.
* Refactored DatabaseBase::sourceStream(), made it possible for descendant classes to alter its behaviour w/o having to redo it completely like Oracle does.
* MySQL class now supports specifying DELIMITER.
* Thrown away the mess of catering for double semicolon. If it's a problem, fix your .sql files!
* Haven't actually touched Oracle.
* Tests!
* Merged the 4 simulated implementations of Database*::replace(). I took diffs, they were nearly identical. I made one based on the IBM DB2 version, since it used insert() which looked like a nice touch.
* Provided the non-simulated implementation of Database*::replace() via a protected member function, and made DatabaseMysql::replace() and DatabaseSqlite::replace() into a wrapper for it.
* Moved the MySQL-specific functionality from masterPosWait(), getSlavePos() and getMasterPos() from DatabaseBase to DatabaseMysql.
* Renamed getStatus() to getMysqlStatus() and moved it to DatabaseMysql. Removed "unimplemented" errors from two other subclasses. Really there's no way another DBMS could or should implement this function.
* Split the LoadMonitor class into a no-op class and a MySQL-specific class, to avoid fatal errors due to the getMysqlStatus() call if other DBMSs tried to use LoadBalancer with multiple servers. Of course there are lots of other reasons it won't work, I'm just fixing the architecture issue here.
And while I have a replicated test setup handy:
* On MySQL 4.1.9 and later, use SHOW SLAVE STATUS to get the lag instead of SHOW PROCESSLIST. This has the advantage of reading zero when there are no events for a while.
* Reverted the public -> protected changes from r90429, except for doQuery() after a review of usage:
** resultObject() is used by lots of things in core and extensions.
** makeSelectOptions() is used by SMW, and if that's going to be public, the other two probably should be too, for consistency.
** doQuery() was used by several things, but mostly by mistake. It's been marked private since r21359 which is before almost all of them. I updated the callers to use query().
* Added "protected" to doQuery() declarations in other database classes.
* Made PG throw a DBQueryError when it gets a query error, instead of DBUnexpectedError. Apparently this mistake goes back to r14625, when exceptions were first introduced. Did it by removing reportQueryError(), the DatabaseBase version works fine.
* Fixed several places where there was an attempt to check for a query error by checking if the result of query() was false. This never worked. Used try/catch instead.
* Made the DBConnectionError messages go on one line so that they don't mess up the formatting in the installer.
* In DatabasePostgres::selectDB(), only disconnect and reconnect if the DB name is actually changing.
* Made DatabasePostgres::schemaExists() less weird and scary.
* Added DatabasePostgres::roleExists() for use by the installer.
* Removed the PostgreSQL-specific hack to make _InstallUser have a default other than "root". Made _InstallUser into a proper DBMS-specific internal variable instead, since every DBMS we support so far needs a different default.
* Removed the $dbName parameters from openConnection/getConnection, and got rid of $this->useAdmin. Implemented a more sophisticated caching scheme instead. Partial revert of r89389 and r81440.
* When connecting as the install user before DB creation, and when testing the web user's credentials, try a few different database names and use whichever one works.
* Instead of connecting as the web user to create tables, I used SET ROLE. It seems cleaner and more like what the other DBMSes do during installation. "SET ROLE wikiuser" requires the same privileges as "CREATE SCHEMA ... AUTHORIZATION wikiuser", so it's unlikely to break anything.
* In the area of web account creation, fixed various minor logic errors and introduced more informative error messages at the submit stage, pre-install. Show a helpful error message if the web user exists already and the install user can't do the relevant SET ROLE.
* Split schema creation out to a separate install step.
* When creating an account as a non-superuser, add the administrative account to the new account's group. This is necessary to avoid a fatal error during installation (bug 28845).
* Removed code which alters an existing web user to have appropriate search paths and permissions. This may break other apps and is not necessary. As in other DBMSes, If the web user exists, it is the responsibility of the sysadmin to ensure that it has appropriate permissions.
* Rewrote setupPLpgSQL() to use the query builder functions.
This patch should allow you to use the $wgSharedDB [with Postgres]
normally, as you would with mysql. Basically this patch creates a
second connection with the shared database and when a query is
made, we check on which connection we should send it.
Patch from Luca Fulchir
