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 1gbhgb-00072C-Vr for pgsql-bugs@arkaria.postgresql.org; Tue, 25 Dec 2018 08:03:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gbhgY-00041w-UX for pgsql-bugs@arkaria.postgresql.org; Tue, 25 Dec 2018 08:03:30 +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 1gbhgW-0003wh-VJ for pgsql-bugs@lists.postgresql.org; Tue, 25 Dec 2018 08:03:30 +0000 Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gbhgR-0005i8-3L for pgsql-bugs@lists.postgresql.org; Tue, 25 Dec 2018 08:03:27 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 8904B21A38; Tue, 25 Dec 2018 03:03:21 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 25 Dec 2018 03:03:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paquier.xyz; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=blyYnjMrHLguwckfxmDq+KJ0VBI eCNzDwWwuPbm+lrE=; b=nsdPhj2+3MWyN15hOpIOf9MFymHntr9MERWOcs4kXoi R3aBE7Z4W50oz01m7SP+AA8cTZ1WCpGuLraFSRHhwKmfLJQNgvt1rOjywjTkXAAz uiJD7d/+VM0Ym6WRDdXFyXGKxeJJ+S6Oi5RgAVxnqsIunF1ebhnGDGNfzrtwxA7K 7jC/4IQYuZf6gnb7Kpt4DpGxpy1woPZFzk4rzVvLshV7ckTQbGxThsTyd+/zlWgQ QVk2cJ6O5YtabOXB2HOD/BeCDFCU+dEc9N+u/dUCTl5NMxk3gyWd38crxQhfku3Y 3hJVURJnzCfzEx9d0bO7pc1jtWBNtZx/WlDB+iI0Ssw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=fm1; bh=blyYnj MrHLguwckfxmDq+KJ0VBIeCNzDwWwuPbm+lrE=; b=XQHGc8cedQojR6M4ur1BQH UguBKwVXOk8toaHJEPyBLws+4Pgl4ykDhnLbMCVYdx0BW4di7dw6Fe+Xw8Kb/btk nkj8JiEebAaLwLOLgZ0ho1d0XetQQiLFPrGFTHF0Kr34Q8biM1OJg/KFNigPKnVV p8l+7STw5kRzSwxn/R5669iQUJMzQP4Vnaiad401cNp8IRW0tdcDR6u27x2ZvA/J +0tYG3J2lXQ8S3bPkrqTX9j0saOpe1u0ni10rxzSnneuv096nvh8grDWjHlJf+44 Ke64gQyxD3vSUCT4SzNZq1vLPUEb6lDCbDRNqskAVk+ciJ01BAumFYcPlG8T4iMA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtkedrudekvddgudduiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecu fedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnegfrhhlucfvnfffucdlje dtmdenucfjughrpeffhffvuffkfhggtggujgesghdtreertddtvdenucfhrhhomhepofhi tghhrggvlhcurfgrqhhuihgvrhcuoehmihgthhgrvghlsehprghquhhivghrrdighiiiqe enucfkphepiedurddvudehrddufeejrdduiedvnecurfgrrhgrmhepmhgrihhlfhhrohhm pehmihgthhgrvghlsehprghquhhivghrrdighiiinecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from paquier.xyz (c137162.net61215.cablenet.ne.jp [61.215.137.162]) by mail.messagingengine.com (Postfix) with ESMTPA id 7BDEFE4384; Tue, 25 Dec 2018 03:03:17 -0500 (EST) Date: Tue, 25 Dec 2018 17:03:14 +0900 From: Michael Paquier To: David Rowley Cc: Amit Langote , digoal@126.com, pgsql-bugs@lists.postgresql.org, PG Bug reporting form Subject: Re: BUG #15565: truncate bug with tables which have temp table inherited Message-ID: <20181225080314.GF2334@paquier.xyz> References: <15565-ce67a48d0244436a@postgresql.org> <0285c6d1-2d11-2f2c-6fae-d4575cdc3c7b@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="+1TulI7fc0PCHNy3" Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --+1TulI7fc0PCHNy3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Dec 25, 2018 at 08:27:19PM +1300, David Rowley wrote: > I glanced at this and was confused at where "newrelation" comes from > and also the single parameter heap_close(). It does not look like it > would compile. Nope, it doesn't. heap_close ought to not normally release the lock either until the transaction has committed. The patch clobbers something that truncate_check_activity() already checks, which is not elegant. I am wondering as well if we could take this occasion for having better isolation testing when it comes to inheritance trees mixing relation persistency. At least for the TRUNCATE case it would be nice to have something. -- Michael --+1TulI7fc0PCHNy3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAlwh5EIACgkQnvQgOdby QH3MWg/9H6pYtWAydQq0oSjtUZVcEpLvsBmH0SuDSmg9surMDGLsVRTI9SXnildu glxGSnMs4qzj/GeJCkJ6Zt+MvwSI4VTtxZg1h3hRs0jwY1ETp8varuExG9RNTL/Q U/R8vDfIlueN+HJwdPB18NzgahgOpsfZlXHMhkMQ4zg/Mxr4zfohAUhCGELXOxr9 cH0z6l5juHFrft1V9QSW7tbueqSqscXVsu2SofmrW0o2X2u0x/jH/2fre48y9Ohj pkJRMwx+Gpf1S7dQvscvJOhKc2ALcaUN4nkfiUUjMh96adfSkq2yxan8eQLIHG1B gwhsiS0zq0/WLn5maxaLF1fSZJdv/eGA5f6Nlc4prDPByNt/mwFaE2CZXLuyDAb0 LLmA6WPY+ax+K16FjXVqMAlMFMO0syF4rt0FlKzNnh7b15x2Y7lEOT6eQZ4cDRG8 +b8pqHhb6ufuV9RySD5UvxoCwWxxy4rbXa4tU2rCOG/EJs+EfO3X/imP21fsbmWf usBY5vG+tTZU7YMAQagKf7nXv86ySzUKZ4s6QzVo66d4QEmPFgzwuqq62WZ5gMK0 deV27gQ2yItYc/LNopzkBpVbTNIlJ2OZ1YbI0k0lViIqrfYb4dBDiGTbLfbWWB70 wNZeGmuyCiL3dQ80qSxeFj0VnQMnSyxAFUeymQon58ZEm79HYt4= =qk8G -----END PGP SIGNATURE----- --+1TulI7fc0PCHNy3--