Line 252 of wiki/includes/HistoryBlob.php reads: $obj->uncompress();

And $obj is unserialized (and sometimes uncompressed) from the text table.

$obj in the backtrace you gave is a HistoryBlobStub ; and as you point out, HistoryBlobStub does not have an uncompress function. The only thing with an uncompress function is ConcatenatedGzipHistoryBlob.

So as a stab in the dark, if you're feeling lucky, you could try this as an ugly hack and see what happens :

--------------------------------------------- // Save this item for reference; if pulling many // items in a row we'll likely use it again. - $obj->uncompress(); + if( $obj instanceof ConcatenatedGzipHistoryBlob ) { + $obj->uncompress(); + } $wgBlobCache = array( $this->mOldId => $obj ); ---------------------------------------------

All the best, Nick.

-----Original Message----- From: wikitech-l-bounces@lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org]On Behalf Of Travis Derouin Sent: Wednesday, 31 January 2007 10:42 AM To: Wikimedia developers Subject: Re: [Wikitech-l] table text is full

Great. Thanks for the help.

So far so good. I fixed the table by increasing max_rows on the table and the file can now grow past 4GB. I've enabled $wgCompressRevisions and run compressOld.php, just waiting for the nightly backup to optimize the table and it should be ok.

We're seeing this error now while grabbing some old revisions from the history of page, any ideas? It only happens on some articles and I did see some debugging output when I ran compressOld.php. It doesn't appear HistoryBlobStub has an uncompress function:

Fatal error: Call to undefined method HistoryBlobStub::uncompress() in wiki/includes/HistoryBlob.php on line 25

Backtrace: * HistoryBlob.php line 257 calls wfBacktrace() * Revision.php line 533 calls HistoryBlobStub::getText() * Revision.php line 677 calls Revision::getRevisionText() * Revision.php line 435 calls Revision::loadText() * Article.php line 522 calls Revision::getRawText() * Article.php line 384 calls Article::fetchContent() * Article.php line 192 calls Article::loadContent() * Article.php line 863 calls Article::getContent() * Wiki.php line 337 calls Article::view() * Wiki.php line 50 calls MediaWiki::performAction() * index.php line 123 calls MediaWiki::initialize()

$flags are:

Array ( [0] => object [1] => utf-8 )

$obj before being unserialized is:

O:15:"HistoryBlobStub":3:{s:6:"mOldId";s:6:"246631";s:5:"mHash";s:32:"c87a9d76bbd59c9a1218c5620fc889dd";s:4:"mRef";s:6:"246631";}

Any help would be appreciated,

Thanks, Travis

On 1/27/07, Brion Vibber brion@pobox.com wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Travis Derouin wrote:

...

We have reached the maximum table size limit of 4GB for our text table

• what's the best way around or to fix this?

Well, the best is probably to use InnoDB tables instead of MyISAM. :)

But see the general documentation which shows a number of possible issues and workarounds: http://dev.mysql.com/doc/refman/5.0/en/full-table.html

Also consider using compression in MediaWiki to save space ($wgCompressRevisions to gzip newly saved revisions, and/or run maintenance/storage/compressOld.php to perform batch compression.) But fix the table first!

• -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFuv2twRnhpk1wk44RAuXaAJ95Vo66bjCOx+CBLONInaeyuje8tQCfV7Nn l7/55qarL9U3NvEpnCbr//8= =aFUU -----END PGP SIGNATURE-----

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l

Ok,

Looking at the structure of things, it looks like the first revision gets stored as a ConcatenatedGzipHistoryBlob which has all of the revisions compressed into one, and subsequent revisions are replaced with Stubs that point to the initial ConcatenatedGzipHistoryBlob revision.

The problem that I'm having is that there is no initial ConcatenatedGzipHistoryBlob revision for these problematic histories, all of the revisions are stubs, which looks like the data was lost for these affected pages when I ran compressOld.php.

This is not good! We have backups, but it will be a pain to fix. Is the best way to load the old back up into a separate db and then do something like

UPDATE current_wiki.text SET current_wiki.text.old_text = backup_wiki.text.old_text, current_wiki.text.old_flags = backup_wiki.text_old_text (assign other relevant fields here) WHERE current_wiki.text.old_id = backup_wiki.text_old_id AND current_wiki.text.old_id in (BAD TEXT ENTRIES)

Or is there something more complicated that's required?

I'm going to try to reproduce what happened to see if I can narrow down the problem.

Travis

I do recall seeing debugging messages printing to stderr when I ran the script, but they didn't look serious at the time.

One issue I've found is that the default function compressWithConcat assumes that the text table can do transactions as it is using dbw->begin and dbw->commit statements. Our text table was initially created with a version 1.3 of Mediawiki and is still a MyISAM table (which doesn't support transactions), so if something goes wrong, there's no opportunity to do a rollback.

I'd suggest at least warning the user of these consequences, or just use the more basic compressOldPages if InnoDB isn't present:

$res = $dbr->query("show table status like 'text';"); if ($row = $dbr->fetchObject($res)) { $engine = $row->Engine; if ($engine != 'InnoDB') { print "Warning the text table is not an InnoDB table, transactions are not supported\n"; $dbr->freeResult( $res ); return; } } $dbr->freeResult( $res );

I've been running compressOld against an original version of the revisions that had problems, it seems to be working, so it might not be a reproducible problem based on which revisions are compressed. I'll look more into it.

Travis

On 1/31/07, Brion Vibber brion@pobox.com wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Travis Derouin wrote:

...

Looking at the structure of things, it looks like the first revision gets stored as a ConcatenatedGzipHistoryBlob which has all of the revisions compressed into one, and subsequent revisions are replaced with Stubs that point to the initial ConcatenatedGzipHistoryBlob revision.

The problem that I'm having is that there is no initial ConcatenatedGzipHistoryBlob revision for these problematic histories, all of the revisions are stubs, which looks like the data was lost for these affected pages when I ran compressOld.php.

This is not good! We have backups, but it will be a pain to fix. Is the best way to load the old back up into a separate db and then do something like

UPDATE current_wiki.text SET current_wiki.text.old_text = backup_wiki.text.old_text, current_wiki.text.old_flags = backup_wiki.text_old_text (assign other relevant fields here) WHERE current_wiki.text.old_id = backup_wiki.text_old_id AND current_wiki.text.old_id in (BAD TEXT ENTRIES)

Should work, yeah...

...

I'm going to try to reproduce what happened to see if I can narrow down the problem.

Great... bugs in that code are not fun. :(

• -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFwSKUwRnhpk1wk44RAliGAJ4ue6MWVhRCosAAHVEnU6VRpakaHwCfUR7m NQUhoUOV13nhqNUZA7Zh4yw= =/YvX -----END PGP SIGNATURE-----

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Travis Derouin wrote:

I figured out what the issue was. If the articles 2nd revision represents the page being moved, the rev_text_id is the same for the first 2 revisions.

When compressOld iterates over the revisions, a ConcatenatedGzipHistoryBlob is initially set to the first text row, but the 2nd revision also points to the same text row and compressOld overwrites the ConcatenatedGzipHistoryBlob with a HistoryBlobStub.

There was already a bug filed for this, I've updated it with more info and added a fix that works for us:

http://bugzilla.wikimedia.org/show_bug.cgi?id=4268

Thanks! Applied on trunk and 1.9 branch...

- -- brion vibber (brion @ pobox.com)

I got the table text full message on one of my wikis and tried this.

mysql is hanging. Should it come back right away or should I wait. The first time I did control-c and then thought that might have been a mistake. Any thoughts?

Jim

On Feb 5, 2007, at 4:09 AM, Domas Mituzas wrote:

On Jan 27, 2007, at 4:12 AM, Travis Derouin wrote:

...

We have reached the maximum table size limit of 4GB for our text table

• what's the best way around or to fix this?

mysql> alter table text AVG_ROW_LENGTH=10240 MAX_ROWS=1000000000;

now this will safely hold 10T on MyISAM too ;-) I'll poke mediawiki table definitions for MyISAM-people.

BTW, MySQL in 5.0 increased default pointer size, so the 4GB datafile size is no longer default maximum.

-- Domas Mituzas -- http://dammit.lt/ -- [[user:midom]]

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l

===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054