Re: [BUG] Re-entering malloc problem when use --enable-nls build postgresql
От | Thomas Munro |
---|---|
Тема | Re: [BUG] Re-entering malloc problem when use --enable-nls build postgresql |
Дата | |
Msg-id | CAEepm=1cQ0GnWBuSyV923tt=jD=E0AOxfsJ9W0A6bbc8Jw_cZw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [BUG] Re-entering malloc problem when use --enable-nls buildpostgresql (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [BUG] Re-entering malloc problem when use --enable-nls buildpostgresql
|
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: