2

I'm running a private mediawiki server on a Gentoo Linux box with Apache, PHP and Postgresql-9.0. Sometimes when one of us tries to upload a PDF file (that's the only type I've ever seen it happen too) we get the error:

MediaWiki internal error.

Original exception: exception 'DBUnexpectedError' with message 'A database error has occurred Query: UPDATE image SET img_size = '1129473',img_width = '1287',img_height = '1789',img_bits = '0',img_media_type = 'OFFICE',img_major_mime = 'application',img_minor_mime = 'pdf',img_timestamp = '2011-08-31 16:39:11 GMT',img_description = '',img_user = '1',img_user_text = 'Dynamphorous',img_metadata = 'a:15:{s:5:"Title";s:0:"";s:7:"Subject";s:0:"";s:8:"Keywords";s:0:"";s:6:"Author";s:0:"";s:8:"Producer";s:20:"Pdf-It version 1.410";s:12:"CreationDate";s:24:"Thu Jul 27 10:10:25 2000";s:7:"ModDate";s:24:"Tue Apr 24 06:38:25 2001";s:6:"Tagged";s:2:"no";s:5:"Pages";s:2:"12";s:9:"Encrypted";s:2:"no";s:5:"pages";a:12:{i:1;a:1:{s:9:"Page size";s:13:"618 x 859 pts";}i:2;a:1:{s:9:"Page size";s:13:"618 x 859 pts";}i:3;a:1:{s:9:"Page size";s:13:"619 x 859 pts";}i:4;a:1:{s:9:"Page size";s:13:"619 x 859 pts";}i:5;a:1:{s:9:"Page size";s:13:"616 x 859 pts";}i:6;a:1:{s:9:"Page size";s:13:"616 x 859 pts";}i:7;a:1:{s:9:"Page size";s:13:"615 x 859 pts";}i:8;a:1:{s:9:"Page size";s:13:"615 x 859 pts";}i:9;a:1:{s:9:"Page size";s:13:"616 x 859 pts";}i:10;a:1:{s:9:"Page size";s:13:"615 x 859 pts";}i:11;a:1:{s:9:"Page size";s:13:"617 x 859 pts";}i:12;a:1:{s:9:"Page size";s:13:"617 x 859 pts";}}s:9:"File size";s:13:"1129473 bytes";s:9:"Optimized";s:2:"no";s:11:"PDF version";s:3:"1.3";s:4:"text";a:13:{i:0;s:3527:"PAPERS

FULL TEXT OF PAPER I'M TRYING TO UPLOAD GOES HERE

";i:12;s:0:"";}}',img_sha1 = '5y3nidgq6von7yjlalvi776tjs8pjbz' WHERE img_name = 'title of paper.pdf' Function: LocalFile::recordUpload2 Error: 1 ERROR: invalid input syntax for type bytea LINE 1: ...'1',img_user_text = 'Dynamphorous',img_metadata = 'a:15:{s:5... ^ ' in /var/www/localhost/htdocs/includes/db/DatabasePostgres.php:1122 Stack trace: 0 /var/www/localhost/htdocs/includes/db/Database.php(538): DatabasePostgres->reportQueryError('ERROR: invalid...', 1, 'UPDATE image S...', 'LocalFile::reco...', false) 1 /var/www/localhost/htdocs/includes/db/Database.php(1212): DatabaseBase->query('UPDATE image S...', 'LocalFile::reco...') 2 /var/www/localhost/htdocs/includes/filerepo/LocalFile.php(891): DatabaseBase->update('image', Array, Array, 'LocalFile::reco...') 3 /var/www/localhost/htdocs/includes/filerepo/LocalFile.php(758): LocalFile->recordUpload2('20110831170017!...', '', '', Array, false, Object(User)) 4 /var/www/localhost/htdocs/includes/upload/UploadBase.php(391): LocalFile->upload('/tmp/phpMxnvZ5', '', '', 1, Array, false, Object(User)) 5 /var/www/localhost/htdocs/includes/specials/SpecialUpload.php(426): UploadBase->performUpload('', '', false, Object(User)) 6 /var/www/localhost/htdocs/includes/specials/SpecialUpload.php(167): SpecialUpload->processUpload() 7 /var/www/localhost/htdocs/includes/SpecialPage.php(559): SpecialUpload->execute(NULL) 8 /var/www/localhost/htdocs/includes/Wiki.php(254): SpecialPage::executePath(Object(Title)) 9 /var/www/localhost/htdocs/includes/Wiki.php(64): MediaWiki->handleSpecialCases(Object(Title), Object(OutputPage), Object(WebRequest)) 10 /var/www/localhost/htdocs/index.php(117): MediaWiki->performRequestForTitle(Object(Title), NULL, Object(OutputPage), Object(User), Object(WebRequest)) 11 {main}

Exception caught inside exception handler: exception 'DBUnexpectedError' with message 'SQL error: ERROR: current transaction is aborted, commands ignored until end of transaction block' in /var/www/localhost/htdocs/includes/db/DatabasePostgres.php:624 Stack trace:

0 /var/www/localhost/htdocs/includes/Interwiki.php(153): DatabasePostgres->fetchRow(false) 1 /var/www/localhost/htdocs/includes/Interwiki.php(57): Interwiki::load('engineering') 2 /var/www/localhost/htdocs/includes/Interwiki.php(34): Interwiki::fetch('Engineering') 3 /var/www/localhost/htdocs/includes/Title.php(2325): Interwiki::isValidInterwiki('Engineering') 4 /var/www/localhost/htdocs/includes/Title.php(131): Title->secureAndSplit() 5 /var/www/localhost/htdocs/includes/Skin.php(2132): Title::newFromText('Engineering: El...') 6 /var/www/localhost/htdocs/includes/Skin.php(2085): Skin->addToSidebar(Array, 'sidebar') 7 /var/www/localhost/htdocs/includes/SkinTemplate.php(493): Skin->buildSidebar() 8 /var/www/localhost/htdocs/includes/OutputPage.php(1615): SkinTemplate->outputPage(Object(OutputPage)) 9 /var/www/localhost/htdocs/includes/Exception.php(164): OutputPage->output() 10 /var/www/localhost/htdocs/includes/Exception.php(191): MWException->reportHTML() 11 /var/www/localhost/htdocs/includes/Exception.php(289): MWException->report() 12 /var/www/localhost/htdocs/includes/Exception.php(348): wfReportException(Object(DBUnexpectedError)) 13 [internal function]: wfExceptionHandler(Object(DBUnexpectedError)) 14 {main}

it then proceeds to give all the metadata from the PDF. (usually the full text of the document)

Several things I know this is not: Not a MIME file type blacklist issue, we upload PDF's all the time. This is also not a PHP upload size limit (the PDF this error is being thrown by right now is only 1.1MB and there are substantially larger files uploaded even right before this one)

Does anyone have any idea what the issue here might be? I dont think that its a encrypted PDF issue or anything silly like that. And it only seems to happen to PDF's that have metadata, such as the full OCR'd text. Thanks in advance to anyone who can help with this.

dynamphorous
  • 276
  • 1
  • 2
  • 13
  • 1
    Does the very bottom of the error message show any further information, beyond parroting the query back at you? – SmallClanger Aug 31 '11 at 16:57
  • Take a look to PostrgeSQL server log - is there anything interesting? – rvs Aug 31 '11 at 17:02
  • SmallClanger, I've filled in the rest of it after the metadata. Sorry for the messyness, it doesnt easily like to format itself correctly – dynamphorous Aug 31 '11 at 17:04
  • Rvs, I don't see anything interesting in STDERR, (where I have postgresql log too) however to that point I don't see anything particularly interesting from postgresql ever in there. Are there specific logging options you think would be useful in this instance? – dynamphorous Aug 31 '11 at 17:09
  • @dynamphorus You man need to turn on query_logging in the postgres config. It's hard to determine what's wrong with the query unless we can see the entire thing. – Dana the Sane Aug 31 '11 at 17:31
  • It looks like `ERROR: invalid input syntax for type byte` is the error you need to invesstigate, which could be a result of the metadata blob not being escaped properly. One workaround might be to switch mediawiki to storing attachments as files, rather than DB Blobs. – SmallClanger Aug 31 '11 at 17:53
  • @Data The Sane, The error I'm getting in the postgresql log is the same as the one above. The point where everythign seems to break down is with the line: Error: 1 ERROR: invalid input syntax for type bytea LINE 1: ...'1',img_user_text = 'Dynamphorous',img_metadata = 'a:15:{s:5... got any ideas what the invalid input syntax for type bytea might mean? – dynamphorous Aug 31 '11 at 18:01
  • @SmallClanger, I think that you are exactly right. You hadn't responded when I started writing my last comment. How do I go about changing that? I thought they were stored as files, but then stored the metadata as DB blobs. Am I misunderstanding that? – dynamphorous Aug 31 '11 at 18:03
  • 1
    @dynamphorous - Scratch that. MW doesn't support DB storage of uploads (my memory is failing me). You're right in that it stores only metadata and writes the file to the filesystem and now that I look, it's a serialized PHP array of some sort. run `select * from _image where img_name like '%pdf%'`; on your wiki DB, it should give you some successful inserts to compare with. Might be a bug in MW when dealing with too much metadata. – SmallClanger Aug 31 '11 at 18:36
  • @SmallClanger, I think you are exactly correct about that, it would explain why "large" pdfs (not in Mb, but in number of words) appear to be more prone to failure. If you write that up as an answer I will accept it as correct. – dynamphorous Aug 31 '11 at 19:44

1 Answers1

0

As discussed, Mediawiki stores only metadata in the DB (as a serialised array), writing the file content to the local filesystem

This appears to be a bug in Mediawiki that causes it to break when handling metadata that's too big, either because it is incorrectly parsing the entire file content as metadata, or because even the 'correct' metadata is too much for it to handle. I'm banking on the latter, since the error you posted conatined the entire PDF content in the UPDATE query.

I'd recommend trying the same PDF file on a clean install of your current MW release to confirm if perhaps one of your existing configuration settings or extensions is the cause; then try it again on the current release (or the 1.18.0 beta) to see if it's still there.

SmallClanger
  • 9,127
  • 1
  • 32
  • 47