Re: postmaster segfaults with HUGE table

Joachim Wieland wrote:
> this query makes postmaster (beta4) die with signal 11:
>
> (echo "CREATE TABLE footest(";
> for i in `seq 0 66000`; do
> echo "col$i int NOT NULL,";
> done;
> echo "PRIMARY KEY(col0));") | psql test
>
>
> ERROR: tables can have at most 1600 columns
> LOG: server process (PID 2140) was terminated by signal 11
> LOG: terminating any other active server processes
> LOG: all server processes terminated; reinitializing

At best you're going to get the error message above: "tables can have at
most 1600 columns". But this is definitely a bug: we end up triggering
this assertion:

TRAP: BadArgument("!(attributeNumber >= 1)", File: "tupdesc.c", Line: 405)

This specific assertion is triggered because we represent attribute
numbers throughout the code base as a (signed) int16 -- the assertion
failure has occurred because an int16 has wrapped around due to
overflow. A fix would be to add a check to DefineRelation() (or even
earlier) to reject CREATE TABLEs with more than "MaxHeapAttributeNumber"
columns. We eventually do perform this check in
heap_create_with_catalog(), but by that point it is too late: various
functions have been invoked that assume we're dealing with a sane number
of columns.

BTW, I noticed that there's an O(n^2) algorithm to check for duplicate
column names in DefineRelation() -- with 60,000 column names that takes
minutes to execute, but an inconsequential amount of time with 1500
column names. So I don't think there's any point rewriting the algorithm
to be faster -- provided we move the check for MaxHeapAttributeNumber
previous to this loop, we should be fine.

Thanks for the report.

-Neil