Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > Tom Lane wrote: >> Although this is in principle a bug fix, it's invasive enough that I'd >> be pretty hesitant to back-patch it, or even to stick it into HEAD >> post-beta. I'm inclined to sign it up for the next commitfest instead.
> Do we have a backpatchable fix for the reported problem? If so, then it > seems a good tradeoff to install this more invasive fix in HEAD only and > apply the simpler fix to back branches. Otherwise, is the proposal to > leave the bug unfixed in back branches? The latter is what I was thinking. Given that issues like this have been there, and gone unreported, since we invented subtransactions, I do not feel too awful about not fixing it in existing branches. It's possible that we could fix just the one issue originally complained of with a smaller patch, but I don't find that approach attractive, because it was also a small leak. The case that seemed nastiest to me is that a FOREACH ... IN ARRAY loop will leak a copy of the entire array if an error causes control to be thrown out of exec_stmt_foreach_a. That could be a lot more leaked data than the querystring of an EXECUTE. I suppose that a fix based on putting PG_TRY blocks into all the affected functions might be simple enough that we'd risk back-patching it, but I don't really want to go that way. 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