Re: BUG #17355: Server crashes on ExecReScanForeignScan in postgres_fdw when accessing foreign partition
От | Etsuro Fujita |
---|---|
Тема | Re: BUG #17355: Server crashes on ExecReScanForeignScan in postgres_fdw when accessing foreign partition |
Дата | |
Msg-id | CAPmGK14sWcZ9wsuCY3pU5uguK2bj2GD=LjE7udCCikFDgSetkg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #17355: Server crashes on ExecReScanForeignScan in postgres_fdw when accessing foreign partition (Alexander Lakhin <exclusion@gmail.com>) |
Ответы |
Re: BUG #17355: Server crashes on ExecReScanForeignScan in postgres_fdw when accessing foreign partition
|
Список | pgsql-bugs |
Hi Alexander, On Tue, Jan 25, 2022 at 3:00 AM Alexander Lakhin <exclusion@gmail.com> wrote: > I've made a simple isolation test (see attachment) to confirm this. And > it crashes without the fix as you said. > With your fix it works as expected Thanks for testing! > (I was wondering how "plan->operation > != CMD_SELECT" with RETURNING will work and I haven't seen any issues yet.) EvalPlanQual rechecking is irrelevant for direct modifications even when the UPDATE/DELETE query has a RETURNING clause; in which case we compute the RETURNING expressions locally, but that is done *after* updating/deleting foreign rows on the remote side. > (Besides that I've observed an infinite waiting for ShareLock with > step "s1i" { INSERT INTO pt VALUES (2000); } > This doesn't happen with a regular (not foreign) table.) You mean the lock wait occurs on the remote side, not on the local side? If so, I think that that is expected behavior because a write conflict occurs on the remote side in that case. Maybe I don’t fully understand your words, so could you elaborate a bit more on your observation? Best regards, Etsuro Fujita
В списке pgsql-bugs по дате отправления: