Last modified: 2012-08-04 20:49:01 UTC
Delete a page, check RecentChanges for the entry, there you see it. Now run rebuildrecentchanges.php. Check RecentChanges... it is gone! The problem is that rebuildrecentchanges.inc assumes that 'log_namespace=page_namespace', 'log_title=page_title', can also be applied to deletions. But deleted pages will not have an entry in the page table! Don't look for them in the page table, instead please separately look for them in the archive table! Users are angry: "Why is the administrator deleting articles behind our backs? If there is a problem with an article I wrote, then go ahead and delete it, but at least don't try to cover up the evidence that you did!" The administrator replies: "The deletions are right there in RecentChanges, along with my carefully worded reasons ... until one day I ran rebuildrecentchanges.php!" (Feel free to recategorized this bug under "Maintenance scripts". I'm just noting that it ruins what is seen on the special page RecentChanges.)
Fixed in r49112
Created attachment 5984 [details] Don't forget newly created users when rebuilding Patch to get 'create'd new users too. Better would be a NOT IN() exclusion list.
(In reply to comment #2) > Created an attachment (id=5984) [details] > Don't forget newly created users when rebuilding > Done in r49136
Bug 13453 points to MySQLisms in r49112. I.e., Catrope: you may have used a mysqlism. Perhaps all such mysqlisms could be grepped for and rooted out of all code?
(In reply to comment #4) > Bug 13453 points to MySQLisms in r49112. > I.e., Catrope: you may have used a mysqlism. > Perhaps all such mysqlisms could be grepped for and rooted out of all code? > It wasn't a MySQLism, since COALESCE() exists in PostgreSQL as well. The problem was that PostgreSQL seems to somehow require that rc_cur_id be a valid page ID or NULL, while we use 0 for this kind of thing pretty much everywhere else. IMO this foreign key should either be reconfigured to allow 0 or be removed.
This bug was resolved, marking back as such.
