| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Neil Conway <neilc(at)samurai(dot)com> |
| Cc: | Joachim Wieland <joe(at)mcknight(dot)de>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: postmaster segfaults with HUGE table |
| Date: | 2004-11-14 23:29:43 |
| Message-ID: | 27650.1100474983@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:
> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Serguei Mokhov | 2004-11-14 23:32:26 | German-style quotes in the source file |
| Previous Message | Neil Conway | 2004-11-14 22:59:16 | Re: code question: storing INTO relation |