Re: PG Seg Faults Performing a Query

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bill Thoen <bthoen(at)gisnet(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Andrej Ricnik-Bay <andrej(dot)groups(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: PG Seg Faults Performing a Query
Date: 2007-08-23 00:35:19
Message-ID: 14623.1187829319@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Bill Thoen <bthoen(at)gisnet(dot)com> writes:
> As you requested, here's what bt in gbd reports:
> (gdb) bt
> #0 0x0000003054264571 in fputc () from /lib64/libc.so.6
> #1 0x000000000040dbd2 in print_aligned_text ()
> #2 0x000000000040f10b in printTable ()
> #3 0x000000000041020b in printQuery ()
> #4 0x0000000000407906 in SendQuery ()
> #5 0x0000000000409153 in MainLoop ()
> #6 0x000000000040b16e in main ()

Hmph. So it looks like it successfully absorbed the query result from
the backend and is dying trying to print it.

What this smells like to me is someplace failing to check for a malloc()
failure result, but I don't see any such places in print.c. And I
didn't have any luck reproducing the problem while exercising 8.1 psql
on 64-bit Fedora 6. I got either "out of memory for query result" or
plain "out of memory", nothing else.

Can you install the postgresql debuginfo RPM, or reproduce this on a
custom build with debugging enabled? Knowing just where the crash
is might help more.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message John DeSoi 2007-08-23 00:56:45 Re: reporting tools
Previous Message Max Zorloff 2007-08-23 00:10:24 CPU load high

Browse pgsql-hackers by date

  From Date Subject
Next Message Ben Tilly 2007-08-23 01:36:15 Re: SQL feature requests
Previous Message Tom Lane 2007-08-23 00:27:55 Re: [COMMITTERS] pgsql: Add configure option --with-system-tzdata to use operating system