Re: postmaster segfaults with HUGE table
От | Tom Lane |
---|---|
Тема | Re: postmaster segfaults with HUGE table |
Дата | |
Msg-id | 12766.1100570922@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: postmaster segfaults with HUGE table (Neil Conway <neilc@samurai.com>) |
Ответы |
Re: postmaster segfaults with HUGE table
|
Список | pgsql-hackers |
Neil Conway <neilc@samurai.com> writes: > On Sun, 2004-11-14 at 11:24 +0000, Simon Riggs wrote: >> 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? > That said, there are some minor logistical problems with testing that a > 70,000 column CREATE TABLE doesn't fail (it would be nice not to have to > include all that text in the regression tests themselves). There are always limits; this just catches the next level up. Are we going to try to test whether the behavior is appropriate when running out of memory to store the tlist? (I think it's OK, but there's surely no regression test for it.) Are we going to test whether the behavior is appropriate when the list length overflows an int32? (I can pretty much guarantee it isn't, but you'll need a 64-bit machine to reach this level before you hit out-of-memory, and you'll need very large quantities of patience as well as RAM.) A regression test for the latter case is silly on its face, though if Moore's law can hold up for another couple decades it might someday not be. regards, tom lane
В списке pgsql-hackers по дате отправления: