Re: DBD::Pg 'lo_read' fails on >= 32768 byte large objects

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: DBD::Pg 'lo_read' fails on >= 32768 byte large objects
Дата
Msg-id 19712.1060970972@sss.pgh.pa.us
обсуждение исходный текст
Ответ на DBD::Pg 'lo_read' fails on >= 32768 byte large objects  (Kevin Houle <kjh@cert.org>)
Ответы Re: DBD::Pg 'lo_read' fails on >= 32768 byte large objects  (Kevin Houle <kjh@cert.org>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: DBD::Pg 'lo_read' fails on >= 32768 byte large objects
Следующее
От: Tom Lane
Дата:
Сообщение: Re: DBD::Pg 'lo_read' fails on >= 32768 byte large objects