I don't have enough dba experience to clearly articulate this, but I am going to try in the hopes that this might lead more knowledgeable people in a useful direction. First, you mentioned that the problem happens when you perform an update. This page only shows SELECT queries, which are evidently not a problem for you.
Personally, I think the problem is due to some sort of deadlock issue rather than the size of your inserts. I'm migrating a zipcode radius search I did in CF/MSSQL to PHP/MySQL which required me to extract 30,000 records containing 4 double-precision floats in PHP using an ODBC driver, and used the record set to generate several SQL insert scripts that are about 600k each. I posted these scripts using a webform to a PHP page that parsed the files and performed the inserts. Approximately 5000 insert queries per request, all executed using a single db request. It worked fine.
I have a couple thoughts on what might be the problem, but it's hard to say without seeing the action page.
Depending on how you designed your database you might keep article details in one table, and then have a generic "Big Text Stuff" table that can be utilized by several different tables, using a foreign key constraint. That probably isn't the case though, since your first query pulls everything from just one table (articles).
My second guess is that your action page executes an update and also runs some sort of select query in order to do some type of housekeeping. What type of tables are you using? I think the default for MySQL 5 is MyISAM, which uses table level locking. InnoDB uses row locking, so is prone to less problems in some instances.
Update queries on MyISAM exclusively lock the whole table down until they're done with their transaction. It supports concurrent selects/updates but that's a problem if you're trying to select a record from the row you're updating. Maybe the added overhead of the longtext field just tips the scales so that the lock isn't given up in time?
If the Select is grabbing from an unrelated row in that table, it should not deadlock. If you're performing a select in order to complete your update statement though, it can't happen because the update takes priority over the select. MySQL knows this and instead of waiting for the server to time out, it just goes ahead and pukes right away.
Want to share the other part of your script? Might be able to offer some insight. Like I said though, I am not a dba. I'm just using a little deduction in the hopes that we can help.