From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: JIT compiling with LLVM v9.0 |
Date: | 2018-01-30 20:06:02 |
Message-ID: | CA+TgmoYvjo=HM_RssEsi=6avgQw+k1eknPBy6tsYfoCzUhes8A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jan 30, 2018 at 2:08 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>> That bites, although it's probably tolerable if we expect such errors
>> only in exceptional situations such as a needed shared library failing
>> to load or something. Killing the session when we run out of memory
>> during JIT compilation is not very nice at all. Does the LLVM library
>> have any useful hooks that we can leverage here, like a hypothetical
>> function LLVMProvokeFailureAsSoonAsConvenient()?
>
> I don't see how that'd help if a memory allocation fails? We can't just
> continue in that case? You could arguably have reserve memory pool that
> you release in that case and then try to continue, but that seems
> awfully fragile.
Well, I'm just asking what the library supports. For example:
https://curl.haxx.se/libcurl/c/CURLOPT_PROGRESSFUNCTION.html
If you had something like that, you could arrange to safely interrupt
the library the next time the progress-function was called.
> The ones I looked at just error out. Needing to handle OOM in soft fail
> manner isn't actually that common a demand, I guess :/.
Bummer.
> I mean we could periodically rescan, rescan after sighup, or such? But
> that seems like something for later to me. It's not going to be super
> common to install new extensions while a lot of sessions are
> running. And things will work in that case, the functions just won't get inlined...
Fair enough.
>> > Do people feel these should be hidden behind #ifdefs, always present but
>> > prevent from being set to a meaningful, or unrestricted?
>>
>> We shouldn't allow non-superusers to set any GUC that dumps files to
>> the data directory or provides an easy to way to crash the server, run
>> the machine out of memory, or similar.
>
> I don't buy the OOM one - there's so so so many of those already...
>
> The profiling one does dump to ~/.debug/jit/ - it seems a bit annoying
> if profiling can only be done by a superuser? Hm :/
The server's ~/.debug/jit? Or are you somehow getting the output to the client?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?= | 2018-01-30 20:07:27 | Re: JIT compiling with LLVM v9.0 |
Previous Message | Robert Haas | 2018-01-30 19:56:06 | Re: [HACKERS] postgres_fdw bug in 9.6 |