Re: Considering signal handling in plpython again

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Considering signal handling in plpython again
Дата
Msg-id F586FBF4-5B82-44CF-A56B-05DB7B2381BD@iki.fi
обсуждение исходный текст
Ответ на Re: Considering signal handling in plpython again  (Hubert Zhang <hzhang@pivotal.io>)
Ответы Re: Considering signal handling in plpython again
Список pgsql-hackers

On 16 May 2018 16:50:24 EEST, Hubert Zhang <hzhang@pivotal.io> wrote:
>There are remaining two problems
>
>1. Do we need to consider when to delete the extension hook or it's not
>necessary?

No, PostgreSQL never unloads shared libraries, so that can be ignored.

We used to, and that's what _PG_fini() was for. But we stopped doing that, because it was unsafe. IIRC, hook functions
likethis was exactly the reason that made it unsafe. 

>2. Do we need to use explicit hook list(List *cancel_hook_list) instead
>of
>implicit cancel_hook(which relies on the extension to link the
>cancel_hook
>inside their code
>     e.g. prev_hook = cancel_hook; cancel_hook=my_hook;   void
>my_hook(){mywork(); (*prev_hook)();} )?
>   I didn't find any explicit hook list in PG code base, is that a good
>practice

I didn't understand what you meant with a hook list. But I believe the way I had the hook in the patch was fine.

- Heikki


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: log_min_messages shows debug instead of debug2
Следующее
От: Alexander Kuzmenkov
Дата:
Сообщение: Removing unneeded self joins