Re: TupleTableSlot abstraction
Michael Paquier <michael@paquier.xyz>
On Tue, Feb 26, 2019 at 09:42:38PM -0800, Andres Freund wrote: > I'm not so sure that's the architecturally correct fix however. Is it > actually guaranteed, given expanded tuples, toasting, etc, that there's > no other memory leak here? I wonder if we shouldn't work twoards using a > short lived memory context here. Note how e.g. printtup() uses a short > lived context for its work. Perhaps. I got to wonder if this change would not impact code using their own DestReceiver, resulting in similar leaks when they insert tuples on-the-fly. Such issues can be surprising for fork an plugin developers. I was playing a bit with some refactoring of relation creation for CTAS in the scope of temporary matviews, and noticed this issue on the CF list, so that was a bit annoying, and issues like that tend to be easily forgotten.. -- Michael
Commits
-
Fix memory leak when inserting tuple at relation creation for CTAS
- 414a9d3cf34c 12.0 landed
-
Build HashState's hashkeys expression with the correct parent.
- 5f32b29c1819 12.0 landed
-
Move TupleTableSlots boolean member into one flag variable.
- c5257345ef61 12.0 landed
-
Move generic slot support functions from heaptuple.c into execTuples.c.
- 9d906f1119de 12.0 landed
-
Remove absolete function TupleDescGetSlot().
- 10763358c3f0 12.0 landed
-
Remove function list from prologue of execTuples.c.
- bbdfbb9154fc 12.0 landed
-
Split ExecStoreTuple into ExecStoreHeapTuple and ExecStoreBufferHeapTuple.
- 29c94e03c7d0 12.0 landed
-
Change TupleTableSlot->tts_nvalid to type AttrNumber.
- a598708ffa8e 12.0 landed
-
Deduplicate code between slot_getallattrs() and slot_getsomeattrs().
- 88ebd62fcc2e 12.0 landed
-
Mention ownership requirements for REFRESH MATERIALIZED VIEW in docs
- ee8012481190 12.0 cited
-
Spell "partitionwise" consistently.
- 31380bc7c204 12.0 cited
-
Fix WHERE CURRENT OF when the referenced cursor uses an index-only scan.
- 8f5ac440430a 11.0 cited