Re: Considering signal handling in plpython again - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Considering signal handling in plpython again
Date
Msg-id F586FBF4-5B82-44CF-A56B-05DB7B2381BD@iki.fi
Whole thread Raw
In response to Re: Considering signal handling in plpython again  (Hubert Zhang <hzhang@pivotal.io>)
Responses Re: Considering signal handling in plpython again
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: log_min_messages shows debug instead of debug2
Next
From: Alexander Kuzmenkov
Date:
Subject: Removing unneeded self joins