Forum OpenACS Q&A: lztext crashes over 8K
I am using PG7.0 and OpenACS 3.2.2 and the lztext for long text gathered from a textbox. When I paste in text that is about 12K, The database barfs.
Here is the error message:
Error: Ns_PgExec: result status: 7 message: ERROR: Tuple is too big: size 8492, max size 8140
I am stuffing the database using ..., bigtext ='$QQbigtext',... into a bigtext field with type lztext.
I understand the limit of a textarea is 32K so how do I extend lztext to match/exceed the textarea limit. Also, does textarea gracefully fail over 32K and truncate the text over 32K without throwing an error? TIA
Rows in Postgres are variable length, so you don't have to worry about each row occupying a full block.
I've avoided putting in limit checks for inserts because version 7.1 of Postgres will have segmented, compressed long types (including text), which will remove the size limit altogether.
Yes, I saw the docs about blocksize... It appears that I would need to do a new installation of pg and loose my current data ? Has anyone saved their data, recompiled pg from 8k to 16k and re-loaded their data successfully? How soon will 7.1 be available which will "solve the problem"?
As a stop gap measure, how would I put a limit check on data before insert/update? It appears that the limit has an effect on the total size of all fields being updated. I can do seperate sql updates for each big field within a begin/end transaction...or do I need to release and get a new handle. In other words, is the tuple the entire size of all the fields together?
I've tried to move text around between textareas but it seems that perhaps ?? some whitespace in the textarea gets counted although I can't see it.
I did this with my own system, changing from type TEXT to type LZTEXT at the same time (by editing the dump) and had no problem.
7.1 is due out this fall.
The size limit is on the row itself, i.e. a row in the database is limited to the size of a database block. 7.1 will store large columns outside the block automatically (much as you do "by hand" in Oracle with CLOBs etc).