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 1izoTD-00029N-87 for pgsql-bugs@arkaria.postgresql.org; Thu, 06 Feb 2020 21:13:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1izoSC-0006lu-0v for pgsql-bugs@arkaria.postgresql.org; Thu, 06 Feb 2020 21:12:52 +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 1izoSB-0006a8-Cz for pgsql-bugs@lists.postgresql.org; Thu, 06 Feb 2020 21:12:51 +0000 Received: from mail-qk1-x741.google.com ([2607:f8b0:4864:20::741]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1izoS8-0007W8-A3 for pgsql-bugs@lists.postgresql.org; Thu, 06 Feb 2020 21:12:49 +0000 Received: by mail-qk1-x741.google.com with SMTP id x1so61290qkl.12 for ; Thu, 06 Feb 2020 13:12:47 -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=PUGBpzF4KyQs9XuHtars7IU9tvPLHcvMNjB4MNsxleI=; b=R9nYCqT4lknlLNkcqNIWE+dE+YO63mDOAA3uXJPOb8yR69seJrzn1+qiGbAd96dQFY bvWZnqB4h5DqS96WGOFPK6bPh9A0dBJwHt6kHgeu7ig7mwLpzjRKHSp7bxDkL0lU7rOL RSBjZFifk8xeiOWara5XOV6pCmX8yphKVXqtUh5nWaTFx3Xn633HDR87F9kGS3Gu/Pgd UR4svZGhxNIFZB356g3mPPnZYt2TEU6+761mkdCZzNPjGosuiFHbHYqAR8VD/bHWZXba RN3EjEC8RNYejzEJQ648Mt1pEG1ZxqRvo78LSF6YSi8GVtqM5/MZlt+wLvfuO+5feDg+ znCg== 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=PUGBpzF4KyQs9XuHtars7IU9tvPLHcvMNjB4MNsxleI=; b=WW7Yo2Dy2LZxrdVhWwdJtlt5P7HyTc3UVnN+18/iX1kwhni8LVjzsNBoHtNwG5LhRv j5Xdc3MW68oQOwn2IMMojvOH0aPwfeSISyT4AHSXoFI/6aqt+rImppNzqBwFG2v5dhe9 3mQi1UXVR+5gdHmaQYcjD18j/sBhaIz+yM1y5V4QsvhKwXsvHjkUCpy4aTcJ/vLRNkF+ aO3ZjB/2R9g4Povy3CnQpgszxDqzeokkKecIOGCmkn9Vv7llLoNW6aTqFepHmYaGKJGI o1jfbLT8+2hdNQBfAT+sRglFhW1RHqScT8sExb9AZFas/Hb67Ja2sAZlGZqwjqs9gO+c zqGg== X-Gm-Message-State: APjAAAX2RxvdeHrkima6Pqk+YKHpfmSnilt/zbRXT7620QSBtg1ZAIUH prJItOrUOTQ/iX30T3hiCI2ytg== X-Google-Smtp-Source: APXvYqydqFRNB5R6liMP/Hd4nxdqgLYUkCep3BqTFPpS9VMxRYbZoy4wpFsAh9Bs2JSmJbz9GCn6iw== X-Received: by 2002:ae9:ebd8:: with SMTP id b207mr4530922qkg.353.1581023566919; Thu, 06 Feb 2020 13:12:46 -0800 (PST) Received: from nimloth.alvh.no-ip.org ([179.56.50.157]) by smtp.gmail.com with ESMTPSA id i4sm265359qkf.111.2020.02.06.13.12.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Feb 2020 13:12:46 -0800 (PST) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id BB2E1300807; Thu, 6 Feb 2020 18:12:38 -0300 (-03) Date: Thu, 6 Feb 2020 18:12:38 -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: <20200206211238.GA29108@alvherre.pgsql> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="J/dobhs11T7y2rNN" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200204183906.115f693e@firost> User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --J/dobhs11T7y2rNN Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit On 2020-Feb-04, Jehan-Guillaume de Rorthais wrote: > Please, find in attachment a bug fix proposal where a truncate on a > partition cascade to the referencing table and truncate all its > partitions if applicable. > > The patch make sure heap_truncate_find_FKs find all referencing relations, > directly **and indirectly** through their parent table. > > When considering the various way of fixing this, I thought about calling > find_all_inheritors on all relations returned by heap_truncate_find_FKs to add > them to the list or relation to truncate (I have a working patch for this as > well). However, I felt like heap_truncate_find_FKs was the real suspect here > and was responsible to find all referencing relations. Hello, thanks for reporting and patching. 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. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services --J/dobhs11T7y2rNN Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v2-0001-Fix-TRUNCATE-on-a-partition-to-apply-CASCADE-to-p.patch"