I wrote:
> If you can use gdb at all, it's not that hard to break on allocations
> into a specific context; I've done it many times. The strategy is
> basically
> 1. Let query run long enough for memory usage to start increasing,
> then attach to backend with gdb.
BTW, just to clarify that strategy a bit: the usage pattern we expect
for ExecutorState is that there are a bunch of individual allocations
during executor startup, but then none while the query is running
(or at least, if there are any in that phase, they get freed before
moving on to the next row). The form of the leak, almost certainly,
is that some allocation is happening per-row and *not* getting freed.
So there's no point in groveling through the startup behavior. What
we want to know about is what happens after we reach the ought-to-be
steady state behavior.
regards, tom lane