Page MenuHomePhabricator

RevisionDelete does not work under Postgres
Closed, ResolvedPublic

Description

Author: overlordq

Description:
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?


Version: 1.16.x
Severity: normal

Details

Reference
bz20150

Related Objects

View Standalone Graph
This task is connected to more than 200 other tasks. Only direct parents and subtasks are shown here. Use View Standalone Graph to show more of the graph.
StatusSubtypeAssignedTask
InvalidNone
Resolvedaaron

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:55 PM
bzimport set Reference to bz20150.

Yes, it is needed...though maybe a different way of expressing it would help PG

overlordq wrote:

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

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.

overlordq wrote:

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".

overlordq wrote:

Committed as r59692, tested and seems to work fine with PG now.

Jdforrester-WMF subscribed.

Migrating from the old tracking task to a tag for PostgreSQL-related tasks.