Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256)
	(Exim 4.89)
	(envelope-from <pgsql-bugs-owner+archive@lists.postgresql.org>)
	id 1h3C31-00021Y-7Z
	for pgsql-bugs@arkaria.postgresql.org; Mon, 11 Mar 2019 03:56:19 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.89)
	(envelope-from <pgsql-bugs-owner+archive@lists.postgresql.org>)
	id 1h3C21-0008J7-Vz
	for pgsql-bugs@arkaria.postgresql.org; Mon, 11 Mar 2019 03:55:17 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
	by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256)
	(Exim 4.89)
	(envelope-from <Langote_Amit_f8@lab.ntt.co.jp>)
	id 1h3C21-0008J0-PY
	for pgsql-bugs@lists.postgresql.org; Mon, 11 Mar 2019 03:55:17 +0000
Received: from tama500.ecl.ntt.co.jp ([129.60.39.148])
	by magus.postgresql.org with esmtp (Exim 4.89)
	(envelope-from <Langote_Amit_f8@lab.ntt.co.jp>)
	id 1h3C1z-0008PE-CC; Mon, 11 Mar 2019 03:55:17 +0000
Received: from vc2.ecl.ntt.co.jp (vc2.ecl.ntt.co.jp [129.60.86.154])
	by tama500.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id x2B3tCwS006065;
	Mon, 11 Mar 2019 12:55:12 +0900
Received: from vc2.ecl.ntt.co.jp (localhost [127.0.0.1])
	by vc2.ecl.ntt.co.jp (Postfix) with ESMTP id 4A72D639A7B;
	Mon, 11 Mar 2019 12:55:12 +0900 (JST)
Received: from jcms-pop21.ecl.ntt.co.jp (jcms-pop21.ecl.ntt.co.jp
 [129.60.87.134])
	by vc2.ecl.ntt.co.jp (Postfix) with ESMTP id 3EED0639A46;
	Mon, 11 Mar 2019 12:55:12 +0900 (JST)
Received: from [127.0.0.1] (unknown [129.60.241.61])
	by jcms-pop21.ecl.ntt.co.jp (Postfix) with ESMTPSA id 34C5D4007A7;
	Mon, 11 Mar 2019 12:55:12 +0900 (JST)
Subject: Re: BUG #15677: Crash while deleting from partitioned table
From: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
References: <15677-0bf089579b4cd02d@postgresql.org>
 <3ad5ba71-d200-96da-f903-7e3b16416140@lab.ntt.co.jp>
Message-ID: <fb946563-ebf1-6bdb-1180-2c392ef31312@lab.ntt.co.jp>
Date: Mon, 11 Mar 2019 12:55:05 +0900
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.5.3
MIME-Version: 1.0
In-Reply-To: <3ad5ba71-d200-96da-f903-7e3b16416140@lab.ntt.co.jp>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-CC-Mail-RelayStamp: 1
To: infernorb@gmail.com, pgsql-bugs@lists.postgresql.org,
        PG Bug reporting form <noreply@postgresql.org>
X-TM-AS-MML: disable
List-Id: <pgsql-bugs.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-bugs@lists.postgresql.org>
List-Owner: <mailto:pgsql-bugs-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-bugs>
Precedence: bulk

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