| 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: | Whole Thread | Raw Message | 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 |