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 1izpfG-00044P-0w for pgsql-bugs@arkaria.postgresql.org; Thu, 06 Feb 2020 22:30:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1izpfD-0005hS-1j for pgsql-bugs@arkaria.postgresql.org; Thu, 06 Feb 2020 22:30:23 +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 ) id 1izpfC-0005hL-MR for pgsql-bugs@lists.postgresql.org; Thu, 06 Feb 2020 22:30:22 +0000 Received: from mail-qv1-xf43.google.com ([2607:f8b0:4864:20::f43]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1izpf9-0006Jw-GU for pgsql-bugs@lists.postgresql.org; Thu, 06 Feb 2020 22:30:21 +0000 Received: by mail-qv1-xf43.google.com with SMTP id db9so81360qvb.3 for ; Thu, 06 Feb 2020 14:30:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=jV8rZR96MQyf5nyHkqpobSvW5fjMnl9lPvq3J8txazs=; b=EhD4jkDoLStkyrYy2DJzbTHjwX2c5SJawFAyvj7TL3wHnzgzPPBHTXMaDADkL9m8qO GtM8h/MlDxCinUvekA6xSawCkj4wqsLhcN95LHYlGF5V3Iqibp4FtA3BuF6ZJ/MQPMtf t6UQ2t2tA6A0UWZ3pz+csC7amaGifWOl9aUGqZFg58i+3qjLQ8oozwUGESAVODEx9+vP T6lj4boAmv6SHBsaNP/3D616ahp8qxNeFpMZg27cKB7prRksRAKWsqD80HepZw2qE1Gf JYmbGNrNcucoGM4NxAmXUQbBn97HvsMOAUFJGHGd2IDVHOTVD8DTZRI7EHqm/jhgCNR6 MRcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=jV8rZR96MQyf5nyHkqpobSvW5fjMnl9lPvq3J8txazs=; b=XOERE55oKXQA35xklrCku3pDZEozRtPI79z55Wk0e0shUfpt4M9U34DWQ3P9v5HHqB Y/HxoIa2CHDzFa7deg/0qYYu/U1PllPFtajnlInWaGyR41etfXIyxCxliDiZGNuuYglE 5/mHwUKz/R9OARE+caC322Fifpmw5WTst+PqUUWAMb63PPpcAS1CbYQMLx3VlpWiwokK PGRg3YXNjjbbKEX6iftphLWFhoq1fdffmiPUcY0p2E+sDCCzs1WFnL3zFqqHQSrWtW8b GRshJndXigJ9UKsDnfejRZdDDh7dGgHhN3symHJjZ41L+mtVCOJ09YLIzw1wTiMXXUzz 1GPw== X-Gm-Message-State: APjAAAXvJtTOrOljoSrjE822ZrpBjf2aM+cCg7ovUiin7YiujAVbtf8i qEaJFU85UdcVYeK1j7hloK6heQ== X-Google-Smtp-Source: APXvYqz6fW1om9TuUQvVT4RLh61ajZu8dAip/6sPic/Z1uf3bs/VC4E3z/L0PxxUaqVhZZ3UrYlxkw== X-Received: by 2002:a05:6214:287:: with SMTP id l7mr4506786qvv.142.1581028217564; Thu, 06 Feb 2020 14:30:17 -0800 (PST) Received: from nimloth.alvh.no-ip.org ([179.56.50.157]) by smtp.gmail.com with ESMTPSA id i28sm388796qtc.57.2020.02.06.14.30.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Feb 2020 14:30:17 -0800 (PST) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id 23698300807; Thu, 6 Feb 2020 19:30:15 -0300 (-03) Date: Thu, 6 Feb 2020 19:30:15 -0300 From: Alvaro Herrera To: Jehan-Guillaume de Rorthais Cc: pgsql-bugs@lists.postgresql.org Subject: Re: FK violation in partitioned table after truncating a referenced partition Message-ID: <20200206223015.GA32754@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200206211238.GA29108@alvherre.pgsql> User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020-Feb-06, Alvaro Herrera wrote: > I agree that patching heap_truncate_find_FKs is a reasonable way to fix. > I propose a slightly different formulation: instead of the loop that you > have, we can just use the second loop, and add more parent constraints > to the list if any constraint we scan in turn has a parent constraint. > So we don't repeat the whole thing, but only that second loop. Hmm, this doesn't actually work; I modified your test case and I see that my code fails to do the right thing. -- Truncate a single partition cascading to another partitioned table. CREATE TABLE trunc_a (a INT PRIMARY KEY) PARTITION BY RANGE (a); CREATE TABLE trunc_a1 PARTITION OF trunc_a FOR VALUES FROM (0) TO (10); CREATE TABLE trunc_a2 PARTITION OF trunc_a FOR VALUES FROM (10) TO (20) PARTITION BY RANGE (a); CREATE TABLE trunc_a21 PARTITION OF trunc_a2 FOR VALUES FROM (10) TO (12); CREATE TABLE trunc_a22 PARTITION OF trunc_a2 FOR VALUES FROM (12) TO (16); CREATE TABLE trunc_a2d PARTITION OF trunc_a2 DEFAULT; CREATE TABLE trunc_a3 PARTITION OF trunc_a FOR VALUES FROM (20) TO (30); INSERT INTO trunc_a VALUES (10), (15), (20), (25); CREATE TABLE ref_c ( c INT PRIMARY KEY, a INT REFERENCES trunc_a(a) ON DELETE CASCADE ) PARTITION BY RANGE (c); CREATE TABLE ref_c1 PARTITION OF ref_c FOR VALUES FROM (100) TO (200); CREATE TABLE ref_c2 PARTITION OF ref_c FOR VALUES FROM (200) TO (300); INSERT INTO ref_c VALUES (100, 10), (150, 15), (200, 20), (250, 25); TRUNCATE TABLE trunc_a21 CASCADE; SELECT a as "from table ref_c" FROM ref_c; SELECT a as "from table trunc_a" FROM trunc_a ORDER BY a; DROP TABLE trunc_a, ref_c; -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services