On 26 February 2011 05:55, Tom Lane <t...@sss.pgh.pa.us> wrote: > Further experimentation has reminded me of why I didn't want to put such > processing in ExecutorEnd :-(. There are some nasty interactions with > EXPLAIN: > > 1. EXPLAIN ANALYZE fails to include the execution cycles associated with > running the ModifyTable nodes to completion. In the worst case, such as > "WITH t AS (INSERT ...) SELECT 1", it will claim the INSERT subplan is > never executed, even though rows certainly got inserted. This is > because EXPLAIN extracts all the counts from the execution state tree > before shutting it down with ExecutorEnd. > > 2. But it gets worse. Try the same query *without* ANALYZE. You'll > find the INSERT executes anyway! That's because EXPLAIN still calls > ExecutorEnd to clean up the execution state tree, and ExecutorEnd > doesn't realize it's not supposed to run any of the plan. >
There's a third problem: AfterTriggerEndQuery() is called before ExecutorEnd(), and so if the post-processing is done in ExecutorEnd() and it attempts to queue up any AFTER triggers, it fails (ERROR: AfterTriggerSaveEvent() called outside of query). > So we really need some refactoring here. I dislike adding another > fundamental step to the ExecutorStart/ExecutorRun/ExecutorEnd sequence, > but there may not be a better way. The only way I see to fix this > without changing that API is to have ExecutorRun do the cleanup > processing just after the top plan node returns a null tuple, and that > seems a bit ugly as well. > > Thoughts? > Could the post-processing not be done at the end of ExecutePlan()? Regards, Dean -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
