Andy Fan <zhihui.fan1213@gmail.com> writes:
> During my recent work, I need some new stuff attached to Relation. Rather
> than adding
> some new data structures, I added it to Relation directly. Like
> relation->balabala. Then
> I initialize it during ExecutorRun, like table_tuple_insert.. and
> destroy it at ExecutorEnd.
at least not if you expect that a relcache reset would not preserve the data.
Thanks for looking into this question.
I am not clear about this sentence . IMO, if the relcache is reset, my data
would be lost, That's why I expect there is no relcache reset happening in
Executor Stage, are you talking about something different?
Also, what happens in the case of nested executor runs touching the same relation?
If you are talking about the RelationClose would be called many times, then
my solution is my resource is only destroyed when the refcount == 0; If you are talking
about the different situation needs different resource types, then that's something
I didn't describe it clearly. At the current time, we can assume "For 1 SQL statement, there
are only 1 resource needed per relation, even the executor or nest executor touch the
same relation many times". I'd like to describe this clearly as well for review purposes,
but I want to focus on one topic only first. So let's first assume my assumption is correct.
Why do you think this ought to be in the relcache, and not in the
executor's rangetable-associated data structures?
I just see the ExecutorEnd code is not called after the exceptions case. and I hope my resource
can be released totally even if the statement raises errors. for example:
CREATE TABLE t(A INT PRIMARY KEY);
INSERT INTO t VALUES(1);
INSERT INTO t VALUES(1);
In the above case, the ExecutorEnd is not called, but the RelationClose will be absolutely called
during the ResourceOwnerRelease call.