Re: postmaster segfaults with HUGE table - Mailing list pgsql-hackers

From Tom Lane
Subject Re: postmaster segfaults with HUGE table
Date
Msg-id 12766.1100570922@sss.pgh.pa.us
Whole thread Raw
In response to Re: postmaster segfaults with HUGE table  (Neil Conway <neilc@samurai.com>)
Responses Re: postmaster segfaults with HUGE table  (Neil Conway <neilc@samurai.com>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: postmaster segfaults with HUGE table
Next
From: Robert Treat
Date:
Subject: Re: Database reverse engineering