Last modified: 2012-08-04 20:48:46 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 20150 - RevisionDelete does not work under Postgres
RevisionDelete does not work under Postgres
Product: MediaWiki
Classification: Unclassified
Revision deletion (Other open bugs)
All All
: Normal normal (vote)
: ---
Assigned To: Aaron Schulz
Depends on:
Blocks: postgres
  Show dependency treegraph
Reported: 2009-08-09 20:45 UTC by OverlordQ
Modified: 2012-08-04 20:48 UTC (History)
0 users

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


Description OverlordQ 2009-08-09 20:45:51 UTC
If you click show/hide on a revision to hide it you get a database error:

A database error has occurred
Query: SELECT log_type,log_action,log_user,log_namespace,log_title,log_params,log_comment,log_id,log_deleted,log_timestamp,user_name,user_editcount,ts_tags FROM logging INNER JOIN mwuser ON ((user_id=log_user)) INNER JOIN log_search ON ((ls_log_id=log_id)) LEFT JOIN tag_summary ON ((ts_log_id=log_id)) WHERE log_type = 'delete' AND log_action = 'revision' AND ls_field = 'rev_id' AND ls_value = '1532' AND (log_type != 'suppress') AND log_namespace = '0' AND log_title = 'Main_Page' AND ((log_deleted & 9) != 9) AND (user_id = log_user) GROUP BY ls_log_id ORDER BY log_timestamp DESC LIMIT 26
Function: IndexPager::reallyDoQuery (LogPager)
Error: 1 ERROR: column "logging.log_type" must appear in the GROUP BY clause or be used in an aggregate function

Is there a reason behind the group-by on that field?
Comment 1 Aaron Schulz 2009-09-02 01:05:00 UTC
Yes, it is needed...though maybe a different way of expressing it would help PG
Comment 2 OverlordQ 2009-10-25 14:13:46 UTC
I'm just wondering why it specifies a group by ls_log_id on the log_search table since as far as I can tell a new log id is generated for every action so a group by on that column is both pointless and bad SQL
Comment 3 Aaron Schulz 2009-10-25 15:39:53 UTC
One log can change several items. If I delete 3 items at once and then view the logs for those three items I'd expect to see that one log entry once rather than three times.
Comment 4 OverlordQ 2009-10-25 20:43:59 UTC
Then why not use DISTINCT instead of group by?

Although we know the rows are the same, the DB doesn't know that, so saying group by ls_log_id it goes "Well which log_type should I return you?" instead of MySQL's "Here's a random log_type".
Comment 5 OverlordQ 2009-12-03 02:38:21 UTC
Committed as r59692, tested and seems to work fine with PG now.

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