Re: PG Seg Faults Performing a Query

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(at)gisnet(dot)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
>
>