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 1j05BT-00023M-D6 for pgsql-bugs@arkaria.postgresql.org; Fri, 07 Feb 2020 15:04:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1j05BR-0003p8-VS for pgsql-bugs@arkaria.postgresql.org; Fri, 07 Feb 2020 15:04:41 +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 1j05BR-0003kw-Bf for pgsql-bugs@lists.postgresql.org; Fri, 07 Feb 2020 15:04:41 +0000 Received: from mail-qt1-x843.google.com ([2607:f8b0:4864:20::843]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1j05BO-00039z-36 for pgsql-bugs@lists.postgresql.org; Fri, 07 Feb 2020 15:04:39 +0000 Received: by mail-qt1-x843.google.com with SMTP id w8so2025299qts.11 for ; Fri, 07 Feb 2020 07:04:37 -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=HeMl/0snmX5ICAgjXH85TcOHgF9pNEbrYStirYhCjOU=; b=IoiwrUmOsWpSxa+rJKbsmb5cc5yVhRaG9jQKXEcHYeo0ge22za8eCVhFQK2SjH7HPP 5tLjonkXNOM9OOxVNgROzLwaIQgeAwvwrgDFjffVL3UqSi4WHwfDcEhdglfIgqpwFDhN Lv/CQjOM5jf5pjXqifTjuUrZkrJnnArvLpmiluaOIlcBFQCHyRfDn7tPVZsi7MOXok5K GdMPyVTdi/U4xsHdW0UN1sMxr4O4+TVVXcFSWEyFI9BIwElq39D7MQ/5BJA5TCCxdeW8 54wJC/47TRsUfl7xWxoToHZtsIgj/adnPdKZ7RMIEI08PgRM3TPEzXqjq5jkVUg6qTK/ RFAQ== 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=HeMl/0snmX5ICAgjXH85TcOHgF9pNEbrYStirYhCjOU=; b=DEJSepjJbihjZUUEgyt7p9umjPk4nQ4Luc61ZX8ohqM0UWbF2WMQWBQviS5NoEomPY PiXCJmOspzv1+h/quTgFnIKUs0Xp9Xo1MbnrjnM3IG2qsJ3nDDIRLO7uXaJMwLsAe2uJ 5sKnzHuIMvDYBIsvLAogftDReBazwiQaHozfo01hLWZeXzMLQEIC9+AqJIte7sYAby6I t5JvjXTNKjxvrjdKVG/Toki8NJnvNVj/fZuKyOyLqwz0VxxUu6dx1FEV/IoaJ6+2IWaj 5MfbgMsOW4XcRQP389GrMf03P8cvQLNSXXoAMB2r0NUAEKgQJT9ge/56Nj6pgnkLYQ2a Zc5Q== X-Gm-Message-State: APjAAAVc5RiffnQVJOvDFWCQnrFls8A60njwvPdUHGLIUp9M6zrcFpxt pQTN8kdGKPIGOx7UmbUrjwi0aOj5j6A= X-Google-Smtp-Source: APXvYqz7yqDEMg33LYOjqJT6duu60mk89vvrtSxJQfFY0OCmr2MbwlfdkBIbvbLpUvcS14epHUxK9g== X-Received: by 2002:ac8:6605:: with SMTP id c5mr7417663qtp.316.1581087875588; Fri, 07 Feb 2020 07:04:35 -0800 (PST) Received: from nimloth.alvh.no-ip.org ([179.56.51.3]) by smtp.gmail.com with ESMTPSA id 184sm1438709qkl.81.2020.02.07.07.04.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 Feb 2020 07:04:34 -0800 (PST) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id 45DD83008D2; Fri, 7 Feb 2020 12:04:32 -0300 (-03) Date: Fri, 7 Feb 2020 12:04:32 -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: <20200207150432.GA21902@alvherre.pgsql> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200207113203.3e26b28d@firost> User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit On 2020-Feb-07, Jehan-Guillaume de Rorthais wrote: > Well, when reading myself, I found a bug in my algorithm. When looking for > parent constraints harvested during the first loop, I wasn't looking on > pg_contraint.oid, but on conparentid again. So instead of gathering parent > constraints to add the parent relation to the list of oids, I was only adding > siblings constraints. Here the fix: > > ScanKeyInit(&key, > - Anum_pg_constraint_conparentid, > + Anum_pg_constraint_oid > BTEqualStrategyNumber, F_OIDEQ, > ObjectIdGetDatum(parent)); > > - fkeyScan = systable_beginscan(fkeyRel, ConstraintParentIndexId, > + fkeyScan = systable_beginscan(fkeyRel, ConstraintOidIndexId, > true, NULL, 1, > &key); Doh, of course. I should have seen that. Here's another take at the formulation; IMO the loop is more obvious this way, with a flag to restart from the top rather than keeping track of the list length. But essentially this is your algorithm. I couldn't find any fault in this. It would be nice if the cascaded truncation was more precise, ie. only truncate the referencing partitions that overlap the ranges covered by the referenced partition being truncated. But that seems more difficult to achieve, as well as less clearly defined; if you really want something like that, I think you can detach the referenced partition. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services --W/nzBZO5zC0uMSeA Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v3-0001-Fix-TRUNCATE-on-a-partition-to-apply-CASCADE-to-p.patch"