From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Kevin Houle <kjh(at)cert(dot)org> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: DBD::Pg 'lo_read' fails on >= 32768 byte large objects |
Date: | 2003-08-15 18:09:32 |
Message-ID: | 19712.1060970972@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Kevin Houle <kjh(at)cert(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Houle | 2003-08-15 20:19:22 | Re: DBD::Pg 'lo_read' fails on >= 32768 byte large objects |
Previous Message | Kevin Houle | 2003-08-15 17:35:12 | Re: DBD::Pg 'lo_read' fails on >= 32768 byte large objects |