Last modified: 2005-10-29 03:04:36 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 T4195, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 2195 - Article deletion fails in most times
Article deletion fails in most times
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Database (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/w/index.php?t...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-17 19:08 UTC by Jay Trees
Modified: 2005-10-29 03:04 UTC (History)
1 user (show)

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


Attachments

Description Jay Trees 2005-05-17 19:08:52 UTC
When attempting to delete an article using the Opera 7.5 web browser, the
browser tries to connect with the database (or squid, perhaps) for about 45
seconds, then returns the following message:

Sorry- we have a problem...
The wikimedia web server didn't return any response to your request.
To get information on what's going on you can visit #wikipedia.
An "offsite" status page is hosted on OpenFacts. 

Generated Wed, 19 Feb 2003 00:34:24 GMT by srv5.wikimedia.org
(squid/2.5.STABLE9.wp20050410.S9plus[icpfix,nortt,htcpclr])

Repeated attempts to delete articles with Opera have returned the same result.
Mozilla Firefox 1.0 has no trouble deleting articles, so perhaps it's a
limitation of the browser but I cannot be sure.
Comment 1 Brion Vibber 2005-06-01 23:25:11 UTC
Works for me, Opera 7.54 on Mac OS X 10.4.1.
Comment 2 Jay Trees 2005-06-06 12:53:44 UTC
Clarifications: The bug occurs in Opera 7.50 build 3778 on Windows ME (Win32). The errors described 
earlier continue to occur with this particular browser.
Comment 3 Brion Vibber 2005-06-06 22:33:57 UTC
Try a more recent build from Opera, and report the bug to Opera if it persists. You might try a 
network sniffer to confirm what's being sent from/to the browser.
Comment 4 Andreas Hörstemeier 2005-06-08 16:23:30 UTC
It's independent on the browser (Firefox here), it only works after many many
tries. But sometimes when the servers have a good day it works on first try, or
only after just one retry.
Comment 5 Jeff Bonham 2005-06-08 18:32:24 UTC
It's independent of the browser, I had to try on-and-off for about half an hour yesterday to 
delete a single page. 
Comment 7 RickK 2005-06-08 21:23:57 UTC
I'm using Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.7.8) Gecko/20050511
Firefox/1.0.4, and it fails in almost all attempts, and has for two days.

RickK
Comment 8 Brion Vibber 2005-06-09 00:24:44 UTC
All deletions, including recently created pages with no history? Or just older pages 
with history? Only on en.wikipedia.org, or also on other wikis?

Could be a bad index or lock contention on the archive table if it's on everything. 
Could be the fancy decompression thingy if it's not.
Comment 9 Brion Vibber 2005-06-09 01:00:18 UTC
Seems to be hitting for even newly created articles on 
enwiki. Investigating...
Comment 10 Brion Vibber 2005-06-09 02:49:35 UTC
It seems to be hanging on the INSERT SELECT from cur to archive, I'm not quite sure why. I've 
temporarily replaced it with separate SELECT and INSERT queries and I haven't seen a failure in my log 
since.

Looking at a deleted page in Special:Undelete also seems to take inordinately long, I'm not quite sure 
why. There may well be something wrong with the archive table...

Oddly I haven't been able to see any of these queries in SHOW PROCESSLIST output, which is somewhat 
maddening as I can't tell which server they're running against, etc.
Comment 11 Brion Vibber 2005-10-29 03:04:36 UTC
A particular entry, was resolved some time ago.

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


Navigation
Links