Re: libpq's multi-threaded SSL callback handling is busted

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: libpq's multi-threaded SSL callback handling is busted
Дата
Msg-id 551DA7CD.3000704@gmx.net
обсуждение исходный текст
Ответ на Re: libpq's multi-threaded SSL callback handling is busted  (Jan Urbański <wulczer@wulczer.org>)
Ответы Re: libpq's multi-threaded SSL callback handling is busted  (Jan Urbański <wulczer@wulczer.org>)
Список pgsql-hackers
On 4/2/15 4:32 AM, Jan Urbański wrote:
> 
> Peter Eisentraut writes:
> 
>> On 2/12/15 7:28 AM, Jan Urbański wrote:
>>> For the sake of discussion, here's a patch to prevent stomping on
>>> previously-set callbacks, racy as it looks.
>>>
>>> FWIW, it does fix the Python deadlock and doesn't cause the PHP segfault...
>>
>> I don't think this patch would actually fix the problem that was
>> described after the original bug report
>> (http://www.postgresql.org/message-id/5436991B.5020708@vmware.com),
>> namely that another thread acquires a lock while the libpq callbacks are
>> set and then cannot release the lock if libpq has been shut down in the
>> meantime.
> 
> I did test both the Python and the PHP repro scripts and the patch fixed both
> the deadlock and the segfault.
> 
> What happens is that Python (for instance) stops over the callback
> unconditionally. So when libpq gets unloaded, it sees that the currently set
> callback is no the one it originally set and refrains from NULLing it.

So this works because Python is just as broken as libpq right now.  What
happens if Python is fixed as well?  Then we'll have the problem I
described above.




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Abbreviated keys for Numeric
Следующее
От: Robert Haas
Дата:
Сообщение: Re: extend pgbench expressions with functions