On Sun, 2004-11-14 at 10:05, Neil Conway wrote: > 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. >
This seems too obvious a problem to have caused a bug...presumably this has been there for a while? Does this mean that we do not have regression tests for each maximum setting ... i.e. are we missing a whole class of tests in the regression tests? -- Best Regards, Simon Riggs ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match