On 2019/03/11 12:02, Amit Langote wrote:
> From the above, I could conclude that EvalPlanQualStart() is not copying
> the value of es_root_result_relations from the parent EState. That means
> ExecInitModifyTable called in the context of EvalPlanQual() checking has
> the wrong value of es_root_result_relations to begin with, so the value it
> computes for rootResultRelInfo for the ModifyTableState it's initializing
> is wrong (0xc0 as seen above).
>
> To reproduce, use these steps (needs 2 sessions to invoke EvalPlanQual at
> all):
>
> Setup:
>
> create table p (a int) partition by list (a);
> create table p1 partition of p for values in (1);
> insert into p values (1);
>
> Session 1:
>
> begin;
> update p set a = a;
>
> Session 2:
>
> with u as (update p set a = a returning p.*) update p set a = u.a from u;
> <blocks>
>
> Session 1:
> commit;
>
> Session 2:
> <invokes-EvalPlanQual-and-crashes>
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
> The connection to the server was lost. Attempting reset: Failed.
>
>
> This can be fixed by the attached patch, which modifies EvalPlanQualStart
> to copy the value of es_root_result_relations from its parent EState.
Forgot to mention that this bug exists in PG 10, 11, and HEAD. The same
patch applies to all three branches.
Thanks,
Amit
