Hi, Whilst working on the stack-based instrumentation patch [0] which adds a new resource owner that gets set up during a query's execution, I encountered the following challenge:
When allocating memory related to a resource, that is intended to be accessed during resource owner cleanup on abort, one cannot use a memory context that's below the active portal (e.g. the executor context), but must instead chose a longer-lived context, often TopMemoryContext. This is caused by the fact that At(Sub)Abort_Portals currently frees all "subsidiary" memory of failed portals (i.e. failed portal memory child contexts), and will be called in Abort(Sub)Transaction before the ResourceOwnerRelease calls. There appears to be no clear reason why the freeing of subsidiary portal memory is being done before resource owner release - one could argue that freeing memory earlier allows a later allocation to re-use it, but the only relevant case I could find was RecordTransactionAbort, and that is already handled with the pre-allocated TransactionAbortContext to make sure we don't fail allocations in out-of-memory aborts. Other non-portal users of the ResOwner infrastructure don't suffer from this problem, as they typically have a memory context set up that survives the abort. If we separate out the freeing of this subsidiary portal memory to run separately, after resource owner cleanup is done (0001 patch), we can remove a handful of uses of TopMemoryContext from the tree in LLVM JIT, WaitEventSet and OpenSSL (0002 patch, passes CI), and make it much less likely that new resource owner code accidentally leaks because it uses the top memory context and missed a pfree. It also happens to make things significantly easier for the stack-based instrumentation patch, since we could rely on the executor context to free memory allocations that need to be accessed during abort (to propagate instrumentation data up the stack). Thoughts? Thanks, Lukas [0]: https://www.postgresql.org/message-id/flat/CAP53PkzdBK8VJ1fS4AZ481LgMN8f9mJiC39ZRHqkFUSYq6KWmg%40mail.gmail.com -- Lukas Fittl
v1-0002-Stop-using-TopMemoryContext-for-resource-owner-re.patch
Description: Binary data
v1-0001-Allow-resource-owners-to-access-subsidiary-portal.patch
Description: Binary data
