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

From: Jan Urbański <wulczer(at)wulczer(dot)org>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: libpq's multi-threaded SSL callback handling is busted
Date: 2015-04-02 08:32:19
Message-ID: 87384igbze.fsf@wulczer.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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.

There's a small race window there, to be sure, but it's a lot better than what
we have now.

Cheers,
Jan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2015-04-02 08:35:43 Re: Logical decoding (contrib/test_decoding) walsender broken in 9.5 master?
Previous Message Pavel Stehule 2015-04-02 07:37:29 Re: PL/pgSQL, RAISE and error context