Re: TRAP: failed Assert("outerPlan != NULL") in postgres_fdw.c
От | Michael Paquier |
---|---|
Тема | Re: TRAP: failed Assert("outerPlan != NULL") in postgres_fdw.c |
Дата | |
Msg-id | aMtRUQqnowiYFIha@paquier.xyz обсуждение исходный текст |
Ответ на | Re: TRAP: failed Assert("outerPlan != NULL") in postgres_fdw.c (Etsuro Fujita <etsuro.fujita@gmail.com>) |
Ответы |
Re: TRAP: failed Assert("outerPlan != NULL") in postgres_fdw.c
|
Список | pgsql-bugs |
On Wed, Sep 17, 2025 at 07:42:36PM +0900, Etsuro Fujita wrote: > The test case you showed upthread and added to the patch is useful, so > I think we should add it as well, but my question about it is: is it > really a good idea to use injection points? > Why don't you just use BEGIN/COMMIT statements like this: > > -- session 1 > begin isolation level read committed; > update a set i = i + 1; > > -- session 2 > begin isolation level read committed; > select a.i, > (select 1 from b, c where a.i = b.i and b.i = c.i) > from a > for update; -- waits for the transaction in session 1 to complete > > -- session 1 > commit; > > -- session 2 > select a.i, > (select 1 from b, c where a.i = b.i and b.i = c.i) > from a > for update; -- produces results after doing an EvalPlanQual recheck > i | ?column? > ---+---------- > 2 | > (1 row) > > Again, my apologies for the late response. As far as I can see, this causes the SELECT FOR UPDATE of session 2 that's waiting for the commit of session 1 to crash, if we don't have the fix, of course. Removing the dependency with injection points is nice if we don't require it, so we can just tweak the isolation test proposed upthread to use the same schema, but the queries you are suggesting. As a whole, +1 for your suggestion. -- Michael
Вложения
В списке pgsql-bugs по дате отправления: