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
---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
