Memory-context slinging

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Well, I would really like a way to register an entire memory context to be
> swept away by elog(ERROR). But that's probably too specialized.

Be careful what you ask for, you might get it ;-).

If you really truly want a context that's destroyed by elog(ERROR),
and not by any other event, then create it as a child of ErrorContext,
and that's what will happen. But I suspect what you really want is a
context that's a child of TopTransactionContext and will go away at
either transaction commit or transaction abort.

A difficulty I have been noticing with some of these special-purpose
contexts is that you'd like to keep a pointer to them in some global
variable, but there's no easy way to determine whether that pointer is
currently valid (eg, whether the context has yet been created during
the current transaction). This would be particularly nasty with
something like a child of ErrorContext --- has an error occurred since
you last used the context?

An example of how we currently have to get around this is
backend/commands/trigger.c's DeferredTriggerAbortXact() routine, which
xact.c has to know to call at transaction abort. All it does is delete
trigger.c's private per-transaction context and reset the global pointer
to same. Deleting the context is useless because that'd happen
automatically anyway when TopTransactionContext gets zapped. So,
resetting the pointer is the only reason for this function to exist.

I've been toying with the notion of adding an optional "notify" callback
function to memory contexts. If specified, it'd be called immediately
before resetting or deleting the context. This'd give you a clean way
to reset pointers etc.

Comments anyone?

regards, tom lane