On Mon, Apr 15, 2019 at 12:34 PM Gunther <raj@gusw.net> wrote:
Breakpoint 2, AllocSetAlloc (context=0x1168230, size=8272) at aset.c:715
715 {
(gdb) p context->name
$8 = 0x96ce5b "ExecutorState"
I think that the above one might have been the one you wanted.
I guess I should run this for a little longer. So I disable my breakpoints
it went up pretty quick from 1.2 GB to 1.5 GB, but then it stopped growing fast, so now back to gdb and break:
Unfortunately, I think this means you missed your opportunity and are now getting backtraces of the innocent bystanders.
Particularly since you report that the version using nested loops rather than hash joins also leaked, so it is probably not the hash-join specific code that is doing it.
What I've done before is compile with the comments removed from
and then look for allocations sizes which are getting allocated but not freed, and then you can go back to gdb to look for allocations of those specific sizes. This generates a massive amount of output, and it bypasses the logging configuration and goes directly to stderr--so it might not end up where you expect.
Thanks for the view definition. Nothing in it stood out to me as risky.
