views:

141

answers:

3

I'm taking the contents of a 1.2mb webpage into a longtext field, server has gone away though everytime!

+2  A: 

This is a known defect.

The LONGTEXT data type in MySQL has a maximum length of 4GB, which is no doubt much larger than your PHP memory_limit.

However, when PHP prepares to receive a query result set, it doesn't know that the content is only 1.2MB. It only sees a query result header that says to expect a LONGTEXT, which might be as large as 4GB. So PHP tries to allocate a 4GB buffer to receive this column, and blows out its memory_limit. This is a fatal error for the PHP instance.

Since PHP doesn't typically know how to use blob-streaming APIs for most databases, there's no workaround for this.

Use the MEDIUMTEXT data type instead. It can store text only up to 16MB, which is large enough for your needs, and PHP can allocate a buffer to receive it.


Here are some bugs that appear to be related:

  • Bug #34623 Segfault when selecting 'longtext' field with pdo/mysql

    Status: Closed 2005-10-19, which implies it was fixed in PHP 5.1.0.

  • Bug #47928 Crash in 'mysqli_stmt_fetch()' with longtext column

    Status: Bogus, not considered a bug in PHP but it is a bug in the mysql client DLL.

@FractalizeR points out in a comment that Zend_Db has a similar bug #1498 reported but never fixed. But the OP doesn't say he is using Zend Framework.

Bill Karwin
What exactly PHP bug do you mean? Did you report it?
FractalizeR
That's not the bug of PHP,l but the bug of Zend_DB:http://framework.zend.com/issues/browse/ZF-1498
FractalizeR
+5  A: 

MySQL's server default *max_allowed_packet* value is 1MB, so you need to tune the configuration if you're handling values larger than that.

see here

jcinacio
This is the correct answer!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Mike
A: 

This is a known problem of Zend_DB which can be still unfixed: http://framework.zend.com/issues/browse/ZF-1498

As Bill Karwin suggests, you should consider moving to MEDIUMTEXT instead.

FractalizeR