On 2018-05-08 01:36:31 -0700, Andres Freund wrote:
> On 2018-05-08 02:07:08 -0400, Tom Lane wrote:
> > Andres Freund <andres@anarazel.de> writes:
> > > On 2018-05-08 01:32:33 -0400, Tom Lane wrote:
> > >> There are not any better alternatives. We can't just set a flag in the
> > >> signal handler and hope that control will someday reach a place that
> > >> notices the flag. We could exit without attempting to report anything,
> > >> but nobody would find that user-friendly. So we try to report, in the
> > >> full understanding that sometimes it won't work.
> >
> > > It'd be fairly unproblematic to write an untranslated message out.
> >
> > 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.
Greetings,
Andres Freund