Last modified: 2011-04-04 21:28:26 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 6905 - Article View and Article Edit show different text after replication.
Article View and Article Edit show different text after replication.
Product: MediaWiki
Classification: Unclassified
Database (Other open bugs)
Other Solaris
: Lowest enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2006-08-02 18:44 UTC by Walt Marthaler
Modified: 2011-04-04 21:28 UTC (History)
0 users

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


Description Walt Marthaler 2006-08-02 18:44:59 UTC
We are testing replication so that we can use the mediwiki on our 
internal servers. We have implemented a slightly different process that 
will still make the last digit of ID specific to the server to insure no 

The problem is when the databaes are disconnected and one server does 
more revisions than the other, the latest revison on a given page by 
timestamp can have a lower rev_id. This causes the view Article page to 
show different text than the Edit Article or History page.

I've located "max(rev_id)" and "ORDER BY rev_id" in the PHP code and 
modified them to get rev_id ordered by timestamp as required by the 
logic. This doesn't seem to have corrected the problem in all cases 

I'm having a bit of trouble determining which code segments the edit 
Article takes to determine the area that might need adjustment. The 
page_latest field in the page record is correct in all cases, but it 
appears different paths are taken to get the text from the database for 
display Article and Edit Article.

Any suggestion on what I might need to look for or even where to look 
besides what I stated above would be appreciated. Unfortunately handling 
the auto increment as stated here 
is not an option, and I would think it would have the same problem in 
the record lookup as I'm experiencing.

This is a great tool and I am looking forward to using it in our 
distributed server environment. Thanks in advance
Comment 1 Walt Marthaler 2006-08-16 21:21:26 UTC
Solved that problem. Doing statement replication with mysql found where the code
was adding a check into the where clause that limited the update to page_latest
= rev_id. Of course the page_latest is different on a system that continued to
have updates while replication was broken for 1 reason or another. Commented
that out.

My current issue is due to replication of innodb tables and/or the fact that
some of the code paths assume that the rev_id is always the highest on the
latest record. This isn't the case when you support distributed processing and
have some outage in connectivity. Guess it's my problem trying to get code to
work in a distributed environment when it wasn't designed that way. I do wish,
however, that there was a little more consistency in how data was accessed.

I only have a day or two left before we have to scrub this and go with a
different wiki so no point in replying to this bug. I guess I'll just change to
WONTFIX since there is no cancel I can find.

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