Re: update db doesnt work

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: dirk heitmann <dirk(dot)heitmann(at)fal(dot)de>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: update db doesnt work
Date: 2002-05-27 20:00:29
Message-ID: 26927.1022529629@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

dirk heitmann <dirk(dot)heitmann(at)fal(dot)de> writes:
> i have created a table with 1600 comlumns. Now i want
> to update some columns with new values:
> update db set col1=1 where col2=2;
> this generates the error-message:
> heap_formtuple: numberOfAttributes of 1601 > 1600.

I've modified current development sources to allow this case to work.
If you are interested in back-porting the patch into existing releases,
modify src/include/access/htup.h as indicated below and change
heap_formtuple in src/backend/access/common/heaptuple.c to test against
MaxTupleAttributeNumber instead of MaxHeapAttributeNumber. (AFAICT all
the other uses of MaxHeapAttributeNumber should stay the same.)

regards, tom lane

/*
* MaxTupleAttributeNumber limits the number of (user) columns in a tuple.
* The key limit on this value is that the size of the fixed overhead for
* a tuple, plus the size of the null-values bitmap (at 1 bit per column),
* plus MAXALIGN alignment, must fit into t_hoff which is uint8. On most
* machines the upper limit without making t_hoff wider would be a little
* over 1700. We use round numbers here and for MaxHeapAttributeNumber
* so that alterations in HeapTupleHeaderData layout won't change the
* supported max number of columns.
*/
#define MaxTupleAttributeNumber 1664 /* 8 * 208 */

/*----------
* MaxHeapAttributeNumber limits the number of (user) columns in a table.
* This should be somewhat less than MaxTupleAttributeNumber. It must be
* at least one less, else we will fail to do UPDATEs on a maximal-width
* table (because UPDATE has to form working tuples that include CTID).
* In practice we want some additional daylight so that we can gracefully
* support operations that add hidden "resjunk" columns, for example
* SELECT * FROM wide_table ORDER BY foo, bar, baz.
* In any case, depending on column data types you will likely be running
* into the disk-block-based limit on overall tuple size if you have more
* than a thousand or so columns. TOAST won't help.
*----------
*/
#define MaxHeapAttributeNumber 1600 /* 8 * 200 */

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Marc G. Fournier 2002-05-27 20:14:42 Re: [meta] news.postgresql.org still down - who do I
Previous Message Gregory Seidman 2002-05-27 19:50:43 Re: Mail messages improvement request