--- Comment #9 from Philippe Verdy <verd...@wanadoo.fr> 2010-12-15 12:40:59 UTC
it looks like there are stale entries in table categorylinks. This is a
referential constraint : one deletion occured in table category, which probably
did not occur at the same time in table cateforylinks, probably due to
concurrent accesses and incorrecct recovery after a failure.
So we need now a SQL-enabled bot to check the counts and cleanup the stale
categorylinks entries. This causes another bug: in debuggging categories
(populated by templates, such as those detecting pages using obsoleted or
missing parameters or incorrect template parameter values), we can cleanup the
listed pages by correcting these template invokations (most of these cleanup
actions are performed by bots).
However, the page reappears in the categoy some minutes later, because
apparently it is found with a request on "categorylinks" only. When we nulledit
these pages, they disappear immedirately from the category, because the query
cache will only list the entries found in the "category" page. A few minutes
later (about 5 minutes), when no edit was really performed, the same pages
reappear without any reason (no edit was performed), because the stale entries
in "categorylinks" are still there and where not deleted by the nulledit.
Checking now all categories could take a lot of time and SQL rssources.
However, a null-edit action should be able to cleanup the categories that the
null-edit is trying to refresh : not only it should look at what is in table
"category" but also if the null-edited page is found somewhere in
"categorylinks", to delete the unwanted stale entries: if the two "SELECT
count(*)" from the two tables are incoherent, then it should list the existing
entries and compare them to what is expected for the null-edited page, and
delete those superfluous entries.
Note that MySQL does not properly rollbacks transactions (a full support for
transactions is very costly for the server and could cause dealys and huge
consumption of ressources, plus additional deadlocks: to avoid this, you should
make sure that deletions or additions in any of the two tables are always
performed in the same order (first "category", then "categorylinks"): this will
remain true if transaction support is enabled (in another engine than MySQL,
such as Oracle or Postgres).
In my opinion, the full support for transaction only works with Oracle, Sybase,
MS-SQL, Informix, Ingres, PostGres, but if transactions is not enabled (i.e.
all requests are autocommitted), then you need a better management of errors
and their recovery (by inserting insert/update/delete requests in a queue list
with a callback to handle the retires with a timed delay, for example by
reinserting the page that failed to update completely in the existing update
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are on the CC list for the bug.
Wikibugs-l mailing list