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 1gbarC-00031W-RR for pgsql-bugs@arkaria.postgresql.org; Tue, 25 Dec 2018 00:46:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gbarA-0007Gr-U2 for pgsql-bugs@arkaria.postgresql.org; Tue, 25 Dec 2018 00:46:00 +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 1gbarA-0007Gj-KX for pgsql-bugs@lists.postgresql.org; Tue, 25 Dec 2018 00:46:00 +0000 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gbar3-0004W9-Dc for pgsql-bugs@lists.postgresql.org; Tue, 25 Dec 2018 00:45:59 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id B57303E9; Mon, 24 Dec 2018 19:45:51 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Mon, 24 Dec 2018 19:45:51 -0500 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=fm3; bh=gHMebrQ1/CnmEKAS2BoC0qU68Nj m5hQfvcs71mu3Qjg=; b=mg6W34lskU1n//KgON5amRqTILY9Nu9qiytSAu0/fBx DA7nFv5DcwDTB6Z9ggsdseXT7RYy4doh183kQExKywHew+RoGTf5bKTmMxOt3Tjx DRvbGSSXQ35qg9Yrc/wKIT1wKI+TFZpOycdfZ9t5OnPDEGvPkBEOqaSSCNJFaLcg RY4IcuYg6QlknRU8xyDohnKgBiVt3OMysH9zLO6ahgmTGw+pt47EHuyyRitX0Mlo YBvEijjVXOJJ9sTbvptkTGVd1Z4G4rDGWM9LkrBan6Zfl/bhhCztNPZFd9Gtu4xJ Q8W4FokcHbSVfmaBCuPODFbqM054SU8eIwn4rGOYQ0Q== 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=fm1; bh=gHMebr Q1/CnmEKAS2BoC0qU68Njm5hQfvcs71mu3Qjg=; b=EMWK9vFsXIw35824+fEaxa qITwlEQmBRA7X9zw762UnLPM8puvqPHKWwHSAYtCV/76hdigKSv5Pkl0K0Ab6Lgz KIOkcH+oikmmfg38e8cBC9RhncndVbpBSZjTLA3OH8pPtWz582L4XqbBP0PLkgpg Rh54b1wBCNOyvGuHDvZ1zWDD+r/AJ0QkpJVJOD5Y/V0sFfMA10WotRwq11Ioyope wAhoEbrx6LXjXoX4/pmF7dU/bbTlf+xu+EsTG0fh52n42m5JAOwI47tmaXnFruJ0 Nx+yhe3x4ev0ZaCIP+D9i+tvC8nGyq7mF6LeUzRvPxONk2Vg8gvwhwdyVvXha4fQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtkedrudekvddgvdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecufghrlhcuvffnffculdefhedmnecujfgurhepfffhvffukfhfgggtuggjsehgtd erredttddvnecuhfhrohhmpefoihgthhgrvghlucfrrghquhhivghruceomhhitghhrggv lhesphgrqhhuihgvrhdrgiihiieqnecuffhomhgrihhnpehpohhsthhgrhgvshhqlhdroh hrghenucfkphepiedurddvudehrddufeejrdduiedvnecurfgrrhgrmhepmhgrihhlfhhr ohhmpehmihgthhgrvghlsehprghquhhivghrrdighiiinecuvehluhhsthgvrhfuihiivg eptd X-ME-Proxy: Received: from paquier.xyz (c137162.net61215.cablenet.ne.jp [61.215.137.162]) by mail.messagingengine.com (Postfix) with ESMTPA id 2FDE010085; Mon, 24 Dec 2018 19:45:48 -0500 (EST) Date: Tue, 25 Dec 2018 09:45:45 +0900 From: Michael Paquier To: digoal@126.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #15565: truncate bug with tables which have temp table inherited Message-ID: <20181225004545.GB2334@paquier.xyz> References: <15565-ce67a48d0244436a@postgresql.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UHN/qo2QbUvPLonB" Content-Disposition: inline In-Reply-To: <15565-ce67a48d0244436a@postgresql.org> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --UHN/qo2QbUvPLonB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Dec 24, 2018 at 09:17:46AM +0000, PG Bug reporting form wrote: > create table public.a (id int); > create temp table a (like public.a) inherits(public.a); This issue is way older than 11. A couple of months ago there has been a discussion about mixing temporary and permanent tables in a partition tree: https://www.postgresql.org/message-id/CAKJS1f94Ojk0og9GMkRHGt8wHTW=ijq5KzJKuoBoqWLwSVwGmw@mail.gmail.com The conclusion of this time was that we don't want to allow mixing relations with different persistencies in the same tree for partitions because those rely on relation cache lookups for their description (PartitionDesc), however inheritance trees have been able to accidently work this way for a long time. This shares a little bit of history with this report as partition trees and inheritance share the same lookups at pg_inherits. So there could be an argument to restrict the definition of inheritance trees with trees mixing relation persistencies. It is hard to say as well that truncate silently bypasses the truncation of a temporary relation from another session if a given session wants to truncate a whole tree. Another approach would be to just live with this issue, as the use case is pretty narrow anyway. -- Michael --UHN/qo2QbUvPLonB Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAlwhfbkACgkQnvQgOdby QH0GLA//ZmX9Hy16KXZDH4RBPsmbLtfXQMJ23RD1D0aM9QyYVYYVpHlwdiSvLCwY 8M6AZwQFNccgakvXS2EsyEI6fMNqYYr4RiiAz9KCmf2tS3LSjgPySKne+h5mu+Dn Y1IyjFGDQ4rT6324RVagmEh42KpYtGnyFuegLMlKDqcuPkC1SCgr5Qi9YtrkrEQt rXQQWgj5d1iidbhJS/CqT1pSUYQSDxJVvS4+TrX4tLJzuKiYRu0eoDxAsQgZY/mQ XWPeB1LQEuPS6RazzOv7cLSH0KyvDLecyzuYClNZDfjPjOntTr1hLD7E6g0/Lht9 4WX7poG8AjsljFJ1hXajMEijDZpqsJroYFOlR1dntO7KS7zcbvPJdCgxICxLt+Bi po///FrkYmieFmhjugZLCnX9OP1Ly+xGf5XAHQNjSrjuHuLOKGyUpZRvOxkwjj8s MrhP4m6ZxXgOM0Dk+yb3RvRWyMPpCpKej7VzRykCwgd3rn0LiIXqCPkQOmpCV3Zn grklcwbYhF/RUsemF625SpaEoDQSPwFNAWcIjkHtvCsqzqILdzjyyMKFfzyzN5zT aIT3UCJ6dJoRU5KfAuAlpVjMWI9NzWsGG44xIDjRnX/QEFlSoRVRMykg2rqSpOj7 KOnPaA7RzPIeRzbM+OnjxBgW2gHI0HhcrTv+Hd+NmGYCDkxxCAM= =AaAO -----END PGP SIGNATURE----- --UHN/qo2QbUvPLonB--