Topic on Project:Support desk

Closing this 3 year old thread. Reason for this error most likely was not-recommended usage of beta versions or a downgrade of MediaWiki, which is not supported. Without an (older) unbroken backup, manual cleanup will be needed.

After updating to 1.20.4, I'm getting the following error whenever I attempt to save any changes to a page: A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: (SQL query hidden) from within function "RecentChange::save". Database returned error "1054: Unknown column 'rc_moved_to_ns' in 'field list' (localhost)".

$wgReadOnly is not set in the LocalSettings.php page.

There are no useful messages in my HTTP access_log or error_log files. Just this: 10.4.34.34 - - [16/Apr/2013:14:36:59 -0400] "POST /wiki/index.php?title=Performance_Testing_Home_Page&action=submit HTTP/1.1" 500 14388

Turning on wgShowSQLErrors reveals the following:

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:
INSERT INTO `recentchanges` (rc_timestamp,rc_cur_time,rc_namespace,rc_title,rc_type,rc_minor,rc_cur_id,rc_user,rc_user_text,rc_comment,rc_this_oldid,rc_last_oldid,rc_bot,rc_moved_to_ns,rc_moved_to_title,rc_ip,rc_patrolled,rc_new,rc_old_len,rc_new_len,rc_deleted,rc_logid,rc_log_type,rc_log_action,rc_params,rc_id) VALUES ('20130416184714','20130416184714','0','Main_Page','0','0','1','2','Wgillo','/* MediaWiki Help */ ','2917','2896','0','0','','10.4.34.34','1','0','4024','4060','0','0',NULL,'','',NULL)
from within function "RecentChange::save". Database returned error "1054: Unknown column 'rc_moved_to_ns' in 'field list' (localhost)".

In your database in the table "recentchanges" the column "rc_moved_to_ns" is missing. This causes the error.

Try running update.php.

I get the same error, running update.php did not help. Can i just add the column manually?

INSERT INTO `recentchanges` (rc_timestamp,rc_cur_time,rc_namespace,rc_title,rc_type,rc_minor,rc_cur_id,rc_user,rc_user_text,rc_comment,rc_this_oldid,rc_last_oldid,rc_bot,rc_moved_to_ns,rc_moved_to_title,rc_ip,rc_patrolled,rc_new,rc_old_len,rc_new_len,rc_deleted,rc_logid,rc_log_type,rc_log_action,rc_params,rc_id) VALUES ('20130420201706','20130420201706','0','Atomorbitale','0','0','55','0','37.49.105.188','','4827','2231','0','0','','37.49.105.188','0','0','2967','2968','0','0',NULL,'','',NULL)


„1054: Unknown column 'rc_moved_to_ns' in 'field list' (localhost)“.

You could add the column, but you have no guarantee that this would solve the base of this problem. It would be better to know, why it is missing. In some cases the installer does not only create empty columns, but also fills them with content (with content, which you do not know). Maybe some other columns are missing as well. So just creating this missing column is not enough.

Ohh, I just found a change in MediaWiki, which might explain why the column is missing (and stays missing after running update.php): https://gerrit.wikimedia.org/r/#/c/17894/ It seems like it has been removed.

Then the question is: Why does MediaWiki still try to use it?

Check, that when you updated MediaWiki, you really deleted all old files and that you really added all new files.

Update your extensions to the newest version for MediaWiki 1.20. Maybe you are still using old versions, which use this field?

If there are some caches on the server, you might want to empty them as well.

Well, the change you found seems to be, if im not mistaken, for the upcoming mediawiki 1.21 , so perhaps it could be possible that these columns are still needed for 1.20?

Nevertheless, i will check my extensions for any outdated versions and report back, as a temporary fix i created these two columns to get my wiki up again...

Oh, you are right. The column is still present in the tables.sql file in MediaWiki 1.20. Sorry.

Maybe you can restore the old contents from that column. If you have a backup of your wiki, where the column is still there, you could copy the contents into that column again. Or, if you have not done too many changes, you could replace your DB with a backup, in which the column is still there. However, as I understand the note in tables.sql, this column has not been used in newer releases anyway.

But I would make sure, that all other columns are there as needed. So what I would check now is, if any other columns are missing in your DB.

I solved it by adding these two columns as shown below:

ALTER TABLE `your_database_name`.`wiki_recentchanges` ADD COLUMN `rc_moved_to_ns` TINYINT(3) UNSIGNED NOT NULL DEFAULT '0'  AFTER `rc_type` , ADD COLUMN `rc_moved_to_title` VARBINARY(255) NOT NULL DEFAULT ''  AFTER `rc_moved_to_ns` ;

So my problem was that I first upgraded to 1.21, from 1.19, and then had to downgrade to 1.20.

You request has error. It needs to: ALTER TABLE `your_database_name`.`wiki_recentchanges` ADD COLUMN `rc_moved_to_ns` TINYINT(3) UNSIGNED NOT NULL DEFAULT '0' AFTER `rc_type` , ADD COLUMN `rc_moved_to_title` VARBINARY(255) NOT NULL AFTER `rc_moved_to_ns`;

DEFAULT expect value

just run this command

alter table recentchanges add column rc_cur_time timestamp default '0000-00-00 00:00:00';

Adding the rc_cur_time column will not fix the "Unknown column 'rc_moved_to_ns' in 'field list'" error.

I think it got clear that if the update.php script cannot update the database, you either have to mnually fix any missing columns while still having the problem that the updater would actually fill some of them maybe and you then still have to figure out what exactly and how you have to put into these columns. This manual approach is climpsy, errorprone and not recommended at all.

The way better solution is to take the backup from directly before the upgrade and to run the update script again. However, if there e.g. has been a failed update attempt in the past, then it is possible that the updater cannot fix the broken database anymore. In that case, the installation most likely either used a beta version at some point in time or a downgrade has been done. Both of this is _not_ recommended or is just not supported, especially not for a production website.