Re: Event Triggers: adding information

[ changing subject line to keep threads of discussion separate ]

On Thu, Jan 24, 2013 at 5:51 AM, Dimitri Fontaine
<dimitri@2ndquadrant.fr> wrote:
> Something like this part:
>
> + -- now try something crazy to ensure we don't crash the backend
> + create function test_event_trigger_drop_function()
> +  returns event_trigger
> +  as $$
> + BEGIN
> +     drop function test_event_trigger2() cascade;
> + END
> + $$ language plpgsql;
> +
> + create function test_event_trigger2() returns event_trigger as $$
> + BEGIN
> +     RAISE NOTICE 'test_event_trigger2: % %', tg_event, tg_tag;
> + END
> + $$ language plpgsql;
> +
> + create event trigger drop_test_a on "ddl_command_start"
> +     when tag in ('create table')
> +    execute procedure test_event_trigger_drop_function();
> +
> + create event trigger drop_test_b on "ddl_command_start"
> +    execute procedure test_event_trigger2();
> +
> + create table event_trigger_fire1 (a int);
> +
> + -- then cleanup the crazy test
> + drop event trigger drop_test_a;
> + drop event trigger drop_test_b;
> + drop function test_event_trigger_drop_function();
>
> The only problem for the regression tests being that there's an OID in
> the ouput, but with your proposed error message that would go away.

This seems reasonable, but looking into it a little further, fixing
the error message is not quite as simple as might be hoped.  It's
coming from fmgr_info, which can't be dissuaded from erroring out if
the function is gone.  We could do the fmgr_info lookup earlier, but
it doesn't really help: if the tuple disappears, then
plpgsql_compile() will eventually be reached and will go splat anyway.

As far as I can see, the only reasonable way to keep this from
exploding is to take AccessShareLock on the function once we've looked
it up, and then repeat the syscache lookup immediately thereafter to
verify that the OID is still present.  If it is, it can't subsequently
go away.  This seems like a pretty expensive solution, though.  At
present event triggers only fire during DDL commands so maybe this is
OK, but if you imagine using it for NOTIFY or DML then it starts to
sound like a cripplingly-high cost.

So I'm not sure what to do.  I'm not thrilled with the idea of leaving
this the way it is, but it's not a big enough problem for me to argue
for ripping event triggers back out in their entirety, either.  So
maybe we just have to live with it until somebody comes up with a
better idea.

Anybody got one?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company