> "Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> > I think so. The problem is that Node struct couldn't be freed safely
> > due to the lack of reference count in its definition. As far as I see
> > plans could be destroyed only when the memory context in which
> > they are placed are destroyed.
>
> This is overly conservative. It should be safe to destroy a plan tree
> via freeObject() if it was created via copyObject() --- and that is
> certainly how the plan would get into a permanent memory context.
>
> Currently, rule definitions are leaked in CacheContext at relcache
> flushes. I plan to start freeing them via freeObject at the beginning
> of the 7.1 development cycle --- I didn't want to risk it during the
> runup to 7.0, but I believe it will work fine.
I don't see any reason, why each saved plan or rule definition shouldn't go into it's own, private
memory context. Then, a simple destruction of the entire context will surely free all it's memory, and I think
itwill also be faster since the en-block allocation, done for many small objects, doesn't need to free all them
separately- it throws away the entire blocks. No need to traverse the node tree, nor any problems with multiple
objectreferences inside the tree.
Since plans are (ought to be) saved via SPI_saveplan(plan), there is already a central point where it can be
done for plans. And a corresponding SPI_freeplan(savedplan) should be easy to create, since the context can be
heldin the SPI plan structure itself.
Needs only some general naming convention for these memory contexts. But something like a
MemoryContext CreateObjectMemoryContext();
that guarantees uniqueness in the context name and no conflicts by using some appropriate prefix in them
shoulddo it.
The overhead, payed for separate contexts is IMHO negligible.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #