On Tue, Mar 26, 2013 at 3:02 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > I tried this and it doesn't work. The "error pathways" you speak about > would be the xact.c entry points to commit and abort transactions; > however, there's a problem with that because some of the commands that > ProcessUtility() deals with have their own transaction management > calls internally; so those would call CommitTransaction() and the > event trigger state would go away, and then when control gets back to > ProcessUtility there would be nothing to clean up. I think we could > ignore the problem, or install smarts in ProcessUtility to avoid calling > event_trigger.c when one of those commands is involved -- but this seems > to me a solution worse than the problem. So all in all I feel like the > macro on top of PG_TRY is the way to go.
I see. :-( > Now there *is* one rather big performance problem in this patch, which > is that it turns on collection of object dropped data regardless of > there being event triggers that use the info at all. That's a serious > drawback and we're going to get complaints about it. So we need to do > something to fix that. Really? Who is going to care about that? Surely that overhead is quite trivial. -- 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
