Hi Joerg,
Thanks for your reply.
I found out that this error was limitation row length of 8000 bytes on
InnoDB. I have check the dump sql file and one particular table is causing
error 139.
What I did is just to use MyISAM engine rather than InnoDB for a specific
table only.
BTW, the machine has 24GB memory and Quad-Core CPU. The platform is RHEL 5.5
x64 and mysql-server-5.0.77-4.el5_4.2.
*Rob Wultsch *and Prabhat Kumar, thanks for your response.
Regards,
James
On Tue, Jul 6, 2010 at 5:19 PM, Joerg Bruehe <joerg.bru...@sun.com> wrote:
> James, all,
>
>
> James Corteciano wrote:
> > Hi All,
> >
> > I have received error message "ERROR 1030 (HY000) at line 167: Got error
> 139
> > from storage engine" when importing dump database to MySQL server. The
> MySQL
> > server is using InnoDB. I have google it and it's something problem on
> > exceeding
> > a row-length limit in the InnoDB table.
>
> you are putting overload on our crystal balls - why don't you tell us
> (at least!) the MySQL version and the platform?
>
>
> "error 139" looks like it is some Unix/Linux.
> On all these platforms, the exit code "139" means the process died
> because of signal 11 ("segmentation violation", "SIGSEGV"),
> and then a core dump was taken (indicated by the value 128).
> 139 == 11 + 128.
>
> You should use your debugger of choice to get a stack backtrace, unless
> this was already done automatically during crash analysis / recovery.
>
>
> >
> > Any have idea how to fix this?
>
> Only when the backtrace is known, there may be some educated guesses
> about the cause of the problem.
> But all such effort is wasted unless you tell the versions.
>
>
> Jörg
>
> --
> Joerg Bruehe, MySQL Build Team, joerg.bru...@sun.com
> ORACLE Deutschland B.V. & Co. KG, Komturstrasse 18a, D-12099 Berlin
> Geschaeftsfuehrer: Juergen Kunz, Marcel v.d. Molen, Alexander v.d. Ven
> Amtsgericht Muenchen: HRA 95603
>
>
