Re: dblink() cursor error/issue (TopMemoryContext)

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Tom Lane wrote:
>> (I wonder whether we can't improve on that, at least for the case of a
>> non-deferred after trigger, which'd have already been fired before we
>> exit the subtransaction. The trick is how to know that there's nothing
>> useful left in the subtransaction's per-transaction memory context ...)

> I think this would require us to be smarter about what pfree's are
> leaving the context empty. Whether this requires us to troll the
> freelist and aggregate contiguous elements, or something even more
> complex, I don't know. The fact that this adds a bit more complexity to
> pfree() worries me.

Yeah, slowing down pfree is not a good idea. The other problem is that
random "leaks" into CurTransactionContext would defeat the optimization.
(In this connection it's scary that xact.c initializes
CurrentMemoryContext to CurTransactionContext at subtransaction start.)

The idea I was toying with was to require the subsystems that
intentionally keep state in subtransaction contexts to Do Something at
subtransaction commit --- either proactively copy that state up to the
parent context (then we could remove the subtransaction context), or
report whether they have anything keeping the subxact context from being
freed. There are only about three subsystems that have this issue
(sinval, triggers, notify, IIRC). We might need to combine these ideas:
sometimes there might be more state there than we really want to copy,
but we don't want to keep the whole context around for, say, one trigger
record.

regards, tom lane