Re: postmaster segfaults with HUGE table

Neil Conway <neilc@samurai.com> writes:
> 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.

Good analysis.  We can't check earlier than DefineRelation AFAICS,
because earlier stages don't know about inherited columns.

On reflection I suspect there are similar issues with SELECTs that have
more than 64K output columns.  This probably has to be guarded against
in parser/analyze.c.
        regards, tom lane