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
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 |