On Mon, Feb 20, 2017 at 6:19 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Thomas Munro <thomas.mu...@enterprisedb.com> writes: >> One practical problem that came up was the need for executor nodes to >> get a chance to do that kind of cleanup before the DSM segment is >> detached. In my patch series I introduced a new node API >> ExecNodeDetach to allow for that. Andres objected that the need for >> that is evidence that the existing protocol is broken and should be >> fixed instead. I'm looking into that. > > The thing that you really have to worry about for this kind of proposal > is "what if the query errors out and we never get to ExecEndNode"? > It's particularly nasty if you're talking about parallel queries where > maybe only one or some of the processes involved detect an error.
I think that's not actually a problem, because we've already got code to make sure that all DSM resources associated with the query get blown away in that case. Of course, that code might have bugs, but if it does, I think it's better to try to fix those bugs than to insert some belt-and-suspenders mechanism for reclaiming every possible chunk of memory in retail fashion, just like we blow up es_query_cxt rather than trying to pfree allocations individually. -- 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
