Robert Haas <robertmh...@gmail.com> writes: > On Mon, Feb 20, 2017 at 6:19 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> 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. Actually, I think we're saying the same thing: rely on the general DSM cleanup mechanism, don't insert extra stuff that you expect will get done by executor shutdown. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers