Re: signal handling in plpython
| От | Mario De Frutos Dieguez |
|---|---|
| Тема | Re: signal handling in plpython |
| Дата | |
| Msg-id | CAFYwGJ1vDhwRj5h1Eigs4yF58EFk+ehbUZyRiVpN41ourh42AA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: signal handling in plpython (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
Hi!
Following your ideas I've made a test [here], only in plpython and seems to works pretty well. I've to make more tests and execute the postgres regress too.
This ad-hoc solution could be enough for now, we don't have shared_preload_libraries as Heikki pointed, because in the next week we need to be able to interrupt plpython functions.
But, I would REALLY LOVE to implement a proper solution for this case, making hooks in Postgres for extensions like Heikki propose or any other proposal. I'm really enjoying to work in the Postgres internals
and at least I'd like to finish this PATCH.
Any suggestion on what do I need to read, similar cases, advices, etc?
Again thank you very much for your time and you invaluable help.
Mario
2016-10-14 15:22 GMT+02:00 Tom Lane <tgl@sss.pgh.pa.us>:
Heikki Linnakangas <hlinnaka@iki.fi> writes:
> On 10/14/2016 04:05 PM, Tom Lane wrote:
>> I wrote:
>>> Py_AddPendingCall is safe to call from a signal handler? That would
>>> be ... quite remarkable.
> Yes, I believe it is.
> https://github.com/python/cpython/blob/ 4b71e63b0616aa2a44c9b13675e4c8 e3c0157481/Python/ceval.c#L422
I don't know whether to laugh or cry, but that code is a joke. Just
silently fail if you can't get the lock?
regards, tom lane
В списке pgsql-hackers по дате отправления: