Re: postmaster segfaults with HUGE table

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: postmaster segfaults with HUGE table
Date: 2004-11-16 02:08:42
Message-ID: 12766.1100570922@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Neil Conway <neilc(at)samurai(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Treat 2004-11-16 03:15:27 Re: Database reverse engineering
Previous Message Tom Lane 2004-11-16 01:53:53 Re: postmaster segfaults with HUGE table