Re: postmaster segfaults with HUGE table

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: postmaster segfaults with HUGE table
Дата
Msg-id 27650.1100474983@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: postmaster segfaults with HUGE table  (Neil Conway <neilc@samurai.com>)
Ответы Re: postmaster segfaults with HUGE table  (Neil Conway <neilc@samurai.com>)
Список pgsql-hackers
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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Serguei Mokhov"
Дата:
Сообщение: German-style quotes in the source file
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: code question: storing INTO relation