On Wed, May 9, 2018 at 7:51 AM, Andres Freund <andres@anarazel.de> wrote:
> On 2018-05-08 01:36:31 -0700, Andres Freund wrote:
>> On 2018-05-08 02:07:08 -0400, Tom Lane wrote:
>> > To stderr, maybe. Across an SSL-encrypted client connection? You're
>> > dreaming.
>>
>> libpq invents an equivalent message when the server closes the
>> connection anyway, IIRC. So that'd not necessarily be too bad.
>
> Oh, also: It looks like it'd actually be relatively easy to give openssl
> its own memory allocator + pool:
> Create a global 'openssl' memory context with preallocation, use
> CRYPTO_set_mem_functions() to make openssl allocations go through small
> wrapper functions around palloc/repalloc/pfree.
>
> It's still not entirely kosher to call into openssl from a signal
> handler because we could be inside openssl - but the window for that is
> a lot smaller than being inside *any* memory allocation.
Can't we use a more traditional signal handling style to defer
execution here? 1. Set an in_OpenSSL flag whenever you're about to
enter OpenSSL. 2. In the SIGQUIT handler, if you find that flag is
set, then just set got_SIGQUIT and return. 3. After you leave the
OpenSSL code, if you see got_SIGQUIT, then run the handler explicitly.
--
Thomas Munro
http://www.enterprisedb.com
