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

From: Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Subject: Re: Can I assume relation would not be invalid during from ExecutorRun to ExecutorEnd
Date: 2021-11-30 09:47:46
Message-ID: CAKU4AWqgn=pYjczw=bqd9xVprrw3negPCeyR0XVWqQ66DvokSQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thanks for everyone's insight so far!

my exception should be that the relcache should not be invalidated _after
> the first relation open_
> in the executor (not the beginning of executorRun)。
>
>
s/exception/expectation.

To be more accurate, my expectation is for a single sql statement, after
the first time I write data into
the relation, until the statement is completed or "aborted and
RelationClose is called in ResourceOwnerRelease",
the relcache reset should never happen.

Since there are many places the write table access methods can be called
like COPY, CAST, REFRESH MATVIEW,
VACUUM and ModifyNode, and it is possible that we can get error in each
place, so I think RelationClose
should be a great places for exceptional case(at the same time, we should
remember to destroy properly for non
exceptional case).

This might be not very professional since I bind some executor related data
into a relcache related struct.
But it should be workable in my modified user case. The most professional
method I can think out is adding
another resource type in ResourceOwner and let ResourceOwnerRelease to
handle the exceptional cases.

--
Best Regards
Andy Fan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2021-11-30 10:25:45 Re: row filtering for logical replication
Previous Message Ram Pratap Maurya 2021-11-30 09:44:29 PostgreSQL server: authentication method 10 not supported