Re: Considering signal handling in plpython again

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Hubert Zhang <hzhang(at)pivotal(dot)io>
Cc: Robert Eckhardt <reckhardt(at)pivotal(dot)io>,pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Considering signal handling in plpython again
Date: 2018-05-16 15:31:28
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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

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 like this was exactly the reason that made it unsafe.

>2. Do we need to use explicit hook list(List *cancel_hook_list) instead
>implicit cancel_hook(which relies on the extension to link the
>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

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

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Kuzmenkov 2018-05-16 15:43:33 Removing unneeded self joins
Previous Message Tom Lane 2018-05-16 15:28:23 Re: log_min_messages shows debug instead of debug2