Last modified: 2010-05-15 15:33:59 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T3057, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 1057 - Database error on Special:Log [MySQL 4.1]
Database error on Special:Log [MySQL 4.1]
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
PC Linux
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch
: 1742 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2004-12-10 08:41 UTC by Binesh Bannerjee
Modified: 2010-05-15 15:33 UTC (History)
1 user (show)

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

Column format change which may fix this [HEAD] (2.45 KB, patch)
2005-02-06 16:41 UTC, Brion Vibber

Description Binesh Bannerjee 2004-12-10 08:41:48 UTC
I get this when I go to my Special:Log...

 A database query syntax error has occurred. This may indicate a bug in the
software. The last attempted database query was:

    SELECT log_type, log_action, log_timestamp, log_user, user_name,
log_namespace, log_title, cur_id, log_comment FROM user, logging LEFT OUTER JOIN
cur ON log_namespace=cur_namespace AND log_title=cur_title WHERE
user_id=log_user ORDER BY log_timestamp DESC LIMIT 0,50 

from within function "". MySQL returned error "1267: Illegal mix of collations
(latin1_swedish_ci,IMPLICIT) and (latin1_bin,IMPLICIT) for operation '='".

I'm running the following:
    MediaWiki ( 1.4beta2 
    PHP ( 4.3.9 (apache) 
    MySQL ( 4.1.7

(I'm also using Apache 1.3.33, if that matters any)

Unfortunately, I have no other info to give... It sort of is that simple tho...
If I just go to the log page, that's what I get.
Comment 1 Brion Vibber 2004-12-10 18:54:11 UTC
Ah, the joys of MySQL 4.1. :P

Having built for older versions, our table definitions don't specify collations or 
character sets. I'm not sure what exactly we'll need to change, and under what 
circumstances it's a problem... Just for some extra background: is this a fresh 
installation of MediaWiki, or an upgrade? Is it a fresh installation of MySQL 4.1, 
or an upgrade from an earlier version of MySQL?
Comment 2 Binesh Bannerjee 2004-12-10 22:20:37 UTC
(In reply to comment #1)
> Just for some extra background: is this a fresh 
> installation of MediaWiki, or an upgrade? Is it a fresh installation of MySQL
> or an upgrade from an earlier version of MySQL?

It never was an existing MediaWiki 1.3.8, if that's what you mean. (I started
from MediaWiki 1.4beta1 (which still had the problem) and then moved to beta2.

As for MySQL, I was always on 4.1...

Comment 3 Binesh Bannerjee 2004-12-10 22:35:15 UTC
I just tested it on another box, with a fresh install of

*MediaWiki ( 1.4beta2 
*PHP ( 5.0.2 (apache) 
*MySQL ( 4.1.7

And, it had the same problem...
Comment 4 Paul Laudanski 2005-02-06 04:01:37 UTC
Running MySQL 4.1.8 gcc built binaries, along with PHP 5.0.3 with both mysql and
mysqli configuration, MediaWiki seems to be working perfectly expect when
accessing Special:Log.  I get the same error as above, a brand new installation
of 1.4 beta 6.

--Paul Laudanski
Comment 5 Paul Laudanski 2005-02-06 15:56:55 UTC
In addition to Special:Log causing this error, Special:Log/delete brings it up
as well.  Is the Special:Log call the only one affected by this?
Comment 6 Brion Vibber 2005-02-06 16:41:48 UTC
Created attachment 272 [details]
Column format change which may fix this [HEAD]

The problem seems to be that log_title is not specified as binary, whereas
cur_title/page_title is. MySQL 4.0 doesn't care, but MySQL 4.1 won't let you
join on those two fields (which the log display does) as it's interpreted their
encodings differently.

Attached is a patch which changes the column definition and adds updaters to
change it in place. The fixes don't patch cleanly against REL1_4;
it would be easy to manually copy in, or you can just run
maintenance/archives/patch-logging-table.sql manually.

I haven't checked this in as I don't have a 4.1 test box set up at the moment
so can't confirm that it does the job, or whether the change in place is
sufficient on an already running 4.1 db. (It may require dropping and
recreating the table, depending on how the charset comes into things and when
and how it's set. If the wrong charset 'sticks' on the alter it might requiring
recreating the table, or else being more specific in the alteration.)
Comment 7 Brion Vibber 2005-03-11 01:20:09 UTC
Tested successfully on MySQL 4.1, committed to 1.4 branch. Had already put into HEAD.
Comment 8 Brion Vibber 2005-03-24 03:13:16 UTC
*** Bug 1742 has been marked as a duplicate of this bug. ***

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