On Tue, Feb 5, 2013 at 10:42 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > A larger issue with the patch is handling of subxacts. A quick test > doesn't reveal any obvious misbehavior, but having the list of objects > dropped by a global variable might be problematic. What if, say, the > event trigger function does something funny in an EXCEPTION block and it > fails? Some clever test case is needed here, I think. Also, if we > reset the variable at EOXact, do we also need to do something at > EOSubXact?
This is an awfully good point, although I think the issue has to do with command boundaries more than subtransactions. Suppose you create two ddl_command_end event triggers, A and B. A contains a DROP IF EXISTS command. Someone runs a toplevel DROP command. Now, A is going to fire first, and that's going to recursively invoke A (which will do nothing the second time) and then B; on return from B, we'll finish running the event triggers for the toplevel command, executing B again. If the list of dropped objects is stored in a global variable, it seems like there are a number of ways this can go wrong. I have not tested the actual behavior of the latest patch, but I think we want to define things so that the pg_event_trigger_dropped_objects() function returns, specifically, the list of objects dropped by the command which caused the event trigger to fire. In other words, in the above example, the first, recursive invocation of B should see the object removed by A's DROP-IF-EXISTS, and the second invocation should see the object removed by the toplevel command. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers