Mysql Error Number 139
Status: Closed Impact on me: None Category:MySQL Server: InnoDB storage engine Severity:S2 (Serious) Version:5.0.45 OS:Any (Linux, Windows) Assigned to: Heikki Tuuri Tags: error 139, innodb View Add Comment Files Developer Edit Submission View Progress Log Contributions [8 Aug 2007 8:11] Mohammad Ashraful Anam Description: Here is my data structure CREATE TABLE `bioinfo` ( `pin` varchar(17) NOT NULL default '', `photo` longblob, `photo_original` longblob, `photostatus` tinyint(1) NOT NULL default '0', `signature` longblob, `signaturestatus` tinyint(1) NOT NULL default '0', `lfingert` longblob, `lfingerstatust` tinyint(1) NOT NULL default '0', `lfingeri` longblob, `lfingerstatusi` tinyint(1) NOT NULL default '0', `rfingeri` longblob, `rfingerstatusi` tinyint(1) NOT NULL default '0', `rfingert` longblob, `rfingerstatust` tinyint(1) NOT NULL default '0', `lfingertemplatet` blob, `lfingertemplatei` blob, `rfingertemplatet` blob, `rfingertemplatei` blob, `lfingerbarcodeitext` longtext NOT NULL, PRIMARY KEY (`pin`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; I have a row with pin='19442695047100023' and about 22K each in the 7 longblob fields and around 450bytes in 4 blob fields. As you can see almost all fields are blobs and there should not be any restriction on any size limit of 8000 for INNODB. But when I try the following query it give 139 error: UPDATE bioinfo SET lfingerbarcodeitext='TkZSI+QCFvQBJgL0AfQBAAD/YwABAAb/dAZxYqATBGD4dUAPCF8GeeAWDlh6mQAXDVnknWAFIFhazSAIH1jfIoEFDFhaPSEJFGROSeEJGGPoVkELcWHQ5eEDE16oBkItHVvfJsIFClguLqItEV/ydYIMCVZ0jWINCFMslkIqGFssquInHmIQviIgC1fs2SIPBVGq3QIsFF8h8SIsF1+u/eIpFWWpBoMvI2ZrCiMPB1D6RaMUDF8eRkMqCWDtSmMLBU93ykMUBlrwzgMGElugzsMnA1Ny/YMHCl8t/mMpEFkcCqQiB1TxDsQJB2MwNiQvC2mxRmQtDW+eZuQlBli0gkQxFV7yjuQQClFQzoQIBln/0sQRDVy91mQwHmpm2qQOIVZl3sQMQlvh4qQKJF848UQtEGdI9gQDDFWn9gQqB25QCkUKBWevEWUsCmswPQUiEGm+SaUwDm8uVgUkDWihaQUgC2klekUeBl+CjqUWElzgnoUNDWOyqUUjDWspsmUmEWaztqUvF2tZvYUOD2TRyaUFCW4nyqUgB2WsycUiE2ms4WUuCWcv5iUqB3E48YUlEGfT9sUGCGnoBkYQGmK+FYYkDGJSImYGCWmwIaYhBGeqLsYoBmenMQYfBmdgNmYSEVUoOkYgAmlXagYDCGklauYuB1nUbeYGCmircmYnA1qxeoYqCF3TfQYOBWPWlmYEBGpWnoYMBGOlvgYmCWCp6uYgA2Qn6gYnCGasAUcjBWUoBockA2TbGscJDGBBGucVImTZRecPBmCoVmcpAmBdWucKFF9ZZscUG2AkeQcYJFikfmcnBWOjgeccEFSnlscfCl3TnWcNEF/anQcRCF0asgcdDFVftgcPClvdzscEAmTnzgcWH1zg0mcHBmLb2ocBCWZf5WcJBmXpAugRD2CfBqgkCVSYDogcC1onGoghFFU2TqgfDmJeXkgNDVvjZggGC2QAAAAABAEHAKgnF////wAEAAA=' WHERE pin='19442695047100023' MySQL said: #1030 - Got error 139 from storage engine But if you notice my table structure, you will see that I have only 1 varchar and 1 text column and their total combined size is less than 2000 bytes which is well below the
Updates: Status: Closed Impact on me: None Category:MySQL Server: InnoDB storage engine Severity:S2 (Serious) Version:4.1.11 OS:Mac OS X (MacOS X 10.3.9) Assigned to: Heikki Tuuri View Add Comment Files Developer Edit Submission View Progress Log Contributions [20 Apr 2005 17:07] Andrew Blee Description: Since upgrading MySQL from version 4.0.xx to 4.1.11, when trying to place data into a record it can fail with the error "#1030 - Got error 139 from storage engine". The problem appears to be if the data reaches a certain size. I first found the problem when trying to import a dump created by phpMyAdmin for one of my tables. I am using the "Standard" install package from MySQL Web site. Running Apple Mac/MacOS X 10.3.9. PHP is https://bugs.mysql.com/bug.php?id=30295 version 4.3.10 (client API is 3.23.49). I use phpMyAdmin to administer the DB, but I have run tests using PHP and the problem still occurs. I have also performed tests on my ISP's server (UNIX based) and the problem also occurs, they are using MySQL client API of 4.1.11. I still have access to a 4.0 server and can import the dump with no problems at all, even using a dump from MySQL 4.1.11 using the "backward compatibility" option in phpMyAdmin. https://bugs.mysql.com/bug.php?id=10035 How to repeat: Create an InnoDB table with 1 INT field and 11 TEXT fields. Create an index on the INT field of type "PRIMARY". In the first 10 text fields, enter as many "a" characters as phpMyAdmin will allow. This is 32000 characters in each field. Leave the last text field empty. Click "Go" to save the changes. This should save without any problems. Then copy/paste field 10 to field 11 and click "Go". This results in a "#1030 - Got error 139 from storage engine" error. If I remove the characters little by little at some point it will work, suggesting a size problem. Please let me know if you need any additional information. [21 Apr 2005 5:02] Heikki Tuuri Hi! In 4.1, to support at least 256-character UTF-8 column prefix indexes, InnoDB stores at least 768 bytes of each column 'internally' to the record. With 11 TEXT fields you will run over the 8000 byte record len limit. ./include/dict0mem.h:159:#define DICT_MAX_COL_PREFIX_LEN 768 I probably need to update the manual. Thank you, Heikki [21 Apr 2005 8:34] Andrew Blee Hi Heikki Many thanks for the reply. I read what you wrote several times, but a lot of it still went over my head, so apologies if what I write below is irrelevant :-) Is this 8000 byte limit you mention the same one mentioned in section 15.17 of the manual, i.e. because of the 16k database page s
Cluster and HA SupportTokuMX SupportMongoDB SupportContact SupportPercona Emergency SupportSupport PoliciesSupport TiersRead MoreConsultingPerformance OptimizationInfrastructure Architecture and DesignHigh AvailabilityUpgrades & MigrationsServer & Database AutomationConsulting PoliciesRead MorePercona Care Software MySQL Database SoftwarePercona ServerPercona XtraDB ClusterPercona XtraBackupPercona TokuDBMySQL mysql error Software DocumentationSoftware RepositoriesRead MoreMongoDB Database SoftwarePercona Server for MongoDBMongoDB Software DocumentationPercona TokuMXRead MoreOpen Source Database ToolsPercona Monitoring and ManagementPercona ToolkitPercona Monitoring PluginsDatabase Tools DocumentationRead MoreDocumentation LibraryFind all the documentation you need to set up and mysql error number manage all our products.Read MoreDownloadsRead More Solutions BuildHighly Scalable Data InfrastructureHighly Available Data InfrastructureData Infrastructure AutomationCloud Data StorageDatabase and Infrastructure Architecture and DesignRead MoreFixPerformance Audit, Tuning and OptimizationServer Audit and StabilizationDatabase Server Outage Restoration24 x 7 ExpertiseData RecoveryRead MoreOptimizeDatabase MonitoringApplication and Server Performance OptimizationInfrastructure Review and Design ServicesExpertise On DemandRead MoreManageRemote Managed ServicesProject Management and AdvisorsTrusted Data AdvisorsDatabase BackupRead More Community Data Performance BlogRead from leading data performance experts in Percona's Official blog.Read MoreEventsView all the information about upcoming events and shows where we can meet up!Read MoreForumsAsk Percona database experts for performance help now in our support forums!Read MoreLet's Get SocialTwitterLinkedInGoogle GroupsFacebookRead MoreMySQL