Re: DBD::Pg 'lo_read' fails on >= 32768 byte large objects - Mailing list pgsql-bugs

From Tom Lane
Subject Re: DBD::Pg 'lo_read' fails on >= 32768 byte large objects
Date
Msg-id 19712.1060970972@sss.pgh.pa.us
Whole thread Raw
In response to DBD::Pg 'lo_read' fails on >= 32768 byte large objects  (Kevin Houle <kjh@cert.org>)
Responses Re: DBD::Pg 'lo_read' fails on >= 32768 byte large objects  (Kevin Houle <kjh@cert.org>)
List pgsql-bugs
Kevin Houle <kjh@cert.org> writes:
>> Can you get us a gdb stack trace from the segfault cases?

> #36 0x40421712 in pqsecure_read () from /usr/lib/libpq.so.3
> #37 0x40421712 in pqsecure_read () from /usr/lib/libpq.so.3
> #38 0x40421712 in pqsecure_read () from /usr/lib/libpq.so.3
> #39 0x40421712 in pqsecure_read () from /usr/lib/libpq.so.3
> ...
> cut thousands of lines; you get the idea

In 7.3.2 pqsecure_read will recurse to self when SSL_read returns
SSL_ERROR_WANT_READ.  I changed the recursion to a loop in 7.3.4.
Evidently, in 7.3.2 it's possible for the recursion to overflow your
alloted stack space before the process uses up its timeslice :-(.
In 7.3.4 the loop simply doesn't exit.

I don't understand why, though.  What I expected would happen is that
the process would busy-wait until more data becomes available from the
connection.  That's not ideal but the full fix seemed safer to postpone
to 7.4.  Can you set up this situation, then attach with gdb to the
connected backend and see what it thinks it's doing?  A stacktrace from
that side of the connection might shed some light.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: DBD::Pg 'lo_read' fails on >= 32768 byte large objects
Next
From: Tom Lane
Date:
Subject: Re: DBD::Pg 'lo_read' fails on >= 32768 byte large objects