Hello, just for clarity, "table is full" was the edge case which consisted of very narrow index, slightly too low MAX_ROWS specification and lots of rows. In 4.1 and earlier versions MySQL was using 4-byte data pointers by default, and to bypass that one has to specify maximum rows and average row size. The specifications we had were good for data area, but bad for index area, which was a function of max_rows and index width. As index was very very narrow, a 2-byte internal index area pointer was picked, which allowed just 64k 1024-byte blocks (thats right, total 64M for indexing per table), which restricted us to ~8 million rows per table. Of course, that was way above the one million we specified :) This is quite unpopular situation (I've never seen anyone hit that before, except on our sites :) - and if we had any other additional index on that table or had wider field or more fields in it, the index pointer would be 4 or 6 bytes, thus allowing bazillion rows. Now, the bad part was that we saw this before, and we knew what causes this, and still didn't change definition (or simply remove it, we run 5.0 for ES, and it doesn't need this specification, this is legacy thing). Still, no need to believe that we ran out of diskspace. BR, -- Domas Mituzas -- http://dammit.lt/ -- [[user:midom]]