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 ) id 1h6WNo-0004Fa-Nx for pgsql-bugs@arkaria.postgresql.org; Wed, 20 Mar 2019 08:15:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1h6WNn-0002uf-BE for pgsql-bugs@arkaria.postgresql.org; Wed, 20 Mar 2019 08:15:31 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h6WNl-0002uS-IH for pgsql-bugs@lists.postgresql.org; Wed, 20 Mar 2019 08:15:31 +0000 Received: from out5-smtp.messagingengine.com ([66.111.4.29]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h6WNe-0006Jj-7T for pgsql-bugs@lists.postgresql.org; Wed, 20 Mar 2019 08:15:28 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 6C53522A67; Wed, 20 Mar 2019 04:15:20 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 20 Mar 2019 04:15:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paquier.xyz; h= date:from:to:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=jlQEw+d55hsI0AaLuDlzYCiBjX5 dS5ZrcsINC0u0qZs=; b=LjWTlJdbIP0RQimOOt+dT+M61gyT7FL46pQjvOpHZsM 983RbZAss7JQcmd/t3PMdIcnbsOmArxvLirlbX2otNi/K/fS+9sGJMJbeGGxG9Q6 VHoN9EGb8GjZ+FjmeqgLIM/CpH7uAfLf8IftrgHoVxAm2Il3+HBCGZozn1Qcq0Bf 5rBQEGTX9toOJBdsjpX1Etw0U3kVYOQ8XZZzNyON5fyR0YllvLfZZqoGAb3DfS1v FhTWMGQZaWnbdoiU0VHzLRAXPwJmu0mIRL6FmywA0g7jUtE+Ko3T98kp/OPGkwgJ rlYi8Y7fsogxQmv5Xhwsm/dc+SItO/0q64UjUDNMriA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=jlQEw+ d55hsI0AaLuDlzYCiBjX5dS5ZrcsINC0u0qZs=; b=Gwh8XgtlLdfnVIig01mJPM bHku87708D3Eao7T4EZCt1UZ0zti7XdWPcXuVQEO52hgDJsNRSrMcoNk0PxSEufc jy5QsRK9jcF6hzwDN3KZSJ72V3dLiP+SoZZF5pn9utAf97OXV15FbMBgJL0RbrE/ FGqiB9DnPk7sbXQTvdGBQ+UPRKXDe0qFTkKPcovkOPmcccww46y0QZCw4oGZKwPZ dqewIQmmJl8YkhvHZTYE114zo948yjyMiVtBic+99iMyQYAOagkRgjtw73PcD51s pvRPL+wQhKAZrjQp5YK7of64Is4f+izJ/Z3ChzH2SlNGGJLeu6mYejemSBZs89Mw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrieehgdduvddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucgfrhhlucfvnfffucdljedtmdenucfjughrpeffhf fvuffkfhggtggujgesghdtreertddtvdenucfhrhhomhepofhitghhrggvlhcurfgrqhhu ihgvrhcuoehmihgthhgrvghlsehprghquhhivghrrdighiiiqeenucfkphepiedurddvud ehrddufeejrdduiedvnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmihgthhgrvghlsehp rghquhhivghrrdighiiinecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from paquier.xyz (c137162.net61215.cablenet.ne.jp [61.215.137.162]) by mail.messagingengine.com (Postfix) with ESMTPA id 31F04E475B; Wed, 20 Mar 2019 04:15:17 -0400 (EDT) Date: Wed, 20 Mar 2019 17:15:14 +0900 From: Michael Paquier To: julian.schauder@gmx.de, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #15703: Segfault in cancelled CALL-Statements Message-ID: <20190320081514.GD26601@paquier.xyz> References: <15703-c12c5bc0ea34ba26@postgresql.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xA/XKXTdy9G3iaIz" Content-Disposition: inline In-Reply-To: <15703-c12c5bc0ea34ba26@postgresql.org> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --xA/XKXTdy9G3iaIz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Mar 19, 2019 at 10:04:55AM +0000, PG Bug reporting form wrote: > there seems to be a SEGFAULT issue with CALL-Procedures once they get > SIGINT'ed. While currently able to reproduce with non-disclosed > functions and data- I am working on a minimal report for public > reproduction. It would be nice to have a reproducible test case. From what I can see, we don't have the definition of "procedure" which gets called at the highest level, so it is not possible to use your example. I have been playing a bit with query cancellations and some nested procedures, but could not see an issue: CREATE TABLE aa (a int); CREATE OR REPLACE PROCEDURE insert_tuples(num_tuples int) AS $func$ BEGIN CALL insert_tuples_inner(num_tuples); END $func$ LANGUAGE plpgsql; CREATE OR REPLACE PROCEDURE insert_tuples_inner(num_tuples int) AS $func$ BEGIN FOR i IN 1..num_tuples LOOP EXECUTE format('INSERT INTO aa VALUES (' || i || ');'); END LOOP; END $func$ LANGUAGE plpgsql; Then just do that in parallel between two sessions. One for the cancellation: while true; do psql -c "select pg_cancel_backend(pid) from pg_stat_activity where pid <> pg_backend_pid() and query ~ 'insert_tuples'"; sleep 5; done And another one for the repeated procedure calls, which uses CALL insert_tuples(1000000) as query to run multiple times. -- Michael --xA/XKXTdy9G3iaIz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAlyR9pIACgkQnvQgOdby QH0twBAAi9O/sqNXwCKqnWUoys7QeVyq5hxBWLMIoT+SdYrCtMQxYi1ElkqdX5op yr7UUIlVwdgD2jLG/OaJRQ8IZEE0KJXAYgQ6ciC9jxbAWr+PPVPfZmeJ+yY0xNDd fSI9N/NxoPxSXIVcw4pEASQvQy6ZrYCIqPVCTJsmKHqEO1fPdefRdu4FopPI+i9c YzFXuti//c2+Ia0iI/qOSsR0qmCmflXDNZY1e8pyh609v14QS2rXOYvf/c0b1uUq TKQQmZKHFsJRkabVufcwQt46/lisNQR5Dz02+lCQPGcdqZZxhABknP/xrkGU/1pc +Bu6yv5o7WXA9gX1af4IX3OFBaHJVOvhTAIYf6Aw8Hvvj5KgqfVsknOpC6yawkFf Cb+pKU4W77rifZoB7uKK7uVhLHkWP5WQZLExeCRRm+PnfXBFtHdya7iCCCgBq9NJ xtsonNQXHILPz138xEh8PoIy8JfvaVAKofeFxW8KBAerT0fP0cLjYM0YPAoYJMVO Azm/zXe3rVCOOLZeNiXpnoECSzedvZdRnj8suQXaHaYCtkKiF8IR4xwT1TX3sIkQ UuLl2Qasf7j7hCtHpl4VZJ2XwLOxoLRbShg7IIWmhZmVIHvZTtcU380vsuQG+Ars x7vJXv/1RZwJWcBTYMcz3tB4dUXIllmqiH3muAZxH1FSaLD/L64= =s9sK -----END PGP SIGNATURE----- --xA/XKXTdy9G3iaIz--