On Mon, Nov 29, 2021 at 10:33 PM Tom Lane <t...@sss.pgh.pa.us> wrote:
> Andy Fan <zhihui.fan1...@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. -- Best Regards Andy Fan
