Re: Can I assume relation would not be invalid during from ExecutorRun to ExecutorEnd

On Mon, Nov 29, 2021 at 10:33 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Andy Fan <zhihui(dot)fan1213(at)gmail(dot)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