Re: PG Seg Faults Performing a Query - Mailing list pgsql-general

From Tom Lane
Subject Re: PG Seg Faults Performing a Query
Date
Msg-id 2555.1187975543@sss.pgh.pa.us
Whole thread Raw
In response to PG Seg Faults Performing a Query  (Bill Thoen <bthoen@gisnet.com>)
Responses Re: PG Seg Faults Performing a Query  (Bill Thoen <bthoen@gisnet.com>)
List pgsql-general
Bill Thoen <bthoen@gisnet.com> writes:
> (gdb) bt
> #0  0x0000003054264571 in fputc () from /lib64/libc.so.6
> #1  0x000000000040dbc2 in print_aligned_text (title=0x0, headers=0x5665d0,
>     cells=0x2aaaaf8fc010, footers=0x557c90,
>     opt_align=0x557ef0 'l' <repeats 18 times>, "rr", 'l' <repeats 12
> times>, "rl lllllll", opt_tuples_only=0 '\0', opt_numeric_locale=0 '\0',
> opt_border=1,
>     encoding=8, fout=0x0) at print.c:448
> #2  0x000000000040f0eb in printTable (title=0x0, headers=0x5665d0,
>     cells=0x2aaaaf8fc010, footers=0x557c90,
>     align=0x557ef0 'l' <repeats 18 times>, "rr", 'l' <repeats 12 times>,
> "rlllll lll", opt=0x7fff3e3be8c0, fout=0x3054442760, flog=0x0) at
> print.c:1551

OK, so the problem is that print_aligned_text is being passed fout = NULL.
Since that wasn't what was passed to printTable, the conclusion must be
that PageOutput() was called and returned NULL --- that is, that its
popen() call failed.  Obviously we should put in some sort of check for
that.  I can see three reasonable responses: either make psql abort
entirely (akin to its out-of-memory behavior), or have it fall back to
not using the pager, either silently or after printing an error
message.  Any thoughts which way to jump?

Meanwhile, the question Bill needs to look into is why popen() is
failing for him.  I'm guessing it's a fork() failure at bottom, but
why so consistent?  strace'ing the psql run might provide some more
info.

            regards, tom lane

pgsql-general by date:

Previous
From: Shelby Cain
Date:
Subject: Re: FATAL: could not reattach to shared memory (Win32)
Next
From: Erik Jones
Date:
Subject: Re: Out of Memory - 8.2.4