From: | "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <tom(at)minnesota(dot)com>, <pgman(at)candle(dot)pha(dot)pa(dot)us>, <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: table schema causes crash |
Date: | 2002-12-20 23:24:29 |
Message-ID: | Pine.LNX.4.33.0212201624140.9154-100000@css120.ihs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, 20 Dec 2002, Tom Lane wrote:
> <tom(at)minnesota(dot)com> writes:
> > authtest=# \d imap_passwd
> > Table "imap_passwd"
> > Column | Type | Modifiers
> > ----------+------------------------+-----------
> > username | character varying(128) | Primary key: imap_passwd_pkey
>
> > *** NOTE: it only shows the first column and none of the other columns ***
>
> What I find even more suspicious is that the "Primary key" footer shows
> up in the table data area. Looking at print_aligned_text, this seems to
> suggest that cells[2] must be NULL --- you would get this kind of
> mistake if the number of non-null cells[] entries is not a multiple of
> the number of non-null headers[] entries. But I surely do not see how
> describeTableDetails would be setting that cell to null --- it does
>
> cells[i * cols + 2] = xmalloc(128 + 128);
>
> and xmalloc() will exit() rather than return null.
This is sounding more and more like a machine with bad memory or a bad
hard drive.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-12-20 23:37:43 | Re: table schema causes crash |
Previous Message | tom | 2002-12-20 23:08:55 | Re: table schema causes crash |