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

Поиск
Список
Период
Сортировка
От Andy Fan
Тема Re: Can I assume relation would not be invalid during from ExecutorRun to ExecutorEnd
Дата
Msg-id CAKU4AWoJyDRCruu7SzKw4NeDgHQ15ZxE_00pSgsFF4FA8LW3yw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Can I assume relation would not be invalid during from ExecutorRun to ExecutorEnd  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Can I assume relation would not be invalid during from ExecutorRun to ExecutorEnd  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Wed, Dec 1, 2021 at 3:33 AM Robert Haas <robertmhaas@gmail.com> wrote:
On Tue, Nov 30, 2021 at 4:47 AM Andy Fan <zhihui.fan1213@gmail.com> wrote:
>> 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.

Well .... I'm not sure why you asked the question and then argued with
the answer you got.

I think you misunderstand me,  I argued with the answer because after I got the
answer and I rethink my problem, I found my question description is not accurate
enough,  so I improved the question and willing discussion again. My exception was
things will continue with something like this:
1. In your new described situation,  your solution still does not work because ...
2. In your new described situation,  the solution would work for sure
3.  your situation is still not cleared enough. 


--
Best Regards
Andy Fan

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Bossart, Nathan"
Дата:
Сообщение: Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code)
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file