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

I'm a bit out of my depth with using these debugging tools and
interpreting their results, but I think the problem is due to the output
being just too big for interactive display. Using the same query with
tighter limits in the WHERE clause works perfectly. When I changed the
SQL script to write output into a table it worked with the same query
using even looser limits in the WHERE clause. So sending output to a
table instead of to the monitor when the queries produce a large amount
of output is reliable, faster and doesn't tie up the machine.

I tried using strace, but it produced so much telemetry and
unfortunately I couldn't understand it anyway that I don't think this
would do me any good. I don't want to bug the PostgreSQL list with a
problem that's probably not a PostgreSQL one, but if someone here would
be willing to help me track down this apparent popen or fork problem I'd
appreciate it. However, I managed to get the results I needed, so we
could also call this "fixed via workaround."

Thanks for the help, Tom and others!
- Bill Thoen

Tom Lane wrote:
> 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
>
>