Re: BUG #17355: Server crashes on ExecReScanForeignScan in postgres_fdw when accessing foreign partition
От | Alexander Lakhin |
---|---|
Тема | Re: BUG #17355: Server crashes on ExecReScanForeignScan in postgres_fdw when accessing foreign partition |
Дата | |
Msg-id | c8b6f183-0cc1-feb4-8bfc-361c35983d8e@gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #17355: Server crashes on ExecReScanForeignScan in postgres_fdw when accessing foreign partition (Etsuro Fujita <etsuro.fujita@gmail.com>) |
Ответы |
Re: BUG #17355: Server crashes on ExecReScanForeignScan in postgres_fdw when accessing foreign partition
|
Список | pgsql-bugs |
Hello Etsura-san, 18.01.2022 11:01, Etsuro Fujita wrote: > On Fri, Jan 7, 2022 at 3:19 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote: >> On Thu, Jan 6, 2022 at 9:00 PM Alexander Lakhin <exclusion@gmail.com> wrote: >>> 06.01.2022 12:56, Etsuro Fujita wrote: >>>> I haven't tried to reproduce this yet > I think a simple reproducer for this issue is: > > 1) Define the partitioned table async_pt as shown by Alexander. > 2) Run concurrent transactions as follows. > > Session A: insert into async_pt values (3000); > Session A: begin; > Session A: update async_pt set a = a; > Session B: delete from async_pt; > Session A: commit; > > The commit in Session A would cause a server crash in Session B due to > the segmentation fault. > > Also, I think a simple reproducer for the “cannot re-evaluate a > Foreign Update or Delete during EvalPlanQual” error is: > > 1) Define the partitioned table async_pt as shown by Alexander. > 2) Run concurrent transactions as follows. > > Session A: insert into async_pt values (3000); > Session A: begin; > Session A: update async_pt set a = a; > Session B: update async_pt set a = a; > Session A: commit; > > The commit in Session A would cause the transaction in Session B to > abort with that error. Thanks for the explanation and the fix! 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 (I was wondering how "plan->operation != CMD_SELECT" with RETURNING will work and I haven't seen any issues yet.) (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.) Best regards, Alexander
Вложения
В списке pgsql-bugs по дате отправления: