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 1gsUzU-0006Ek-SY for pgsql-hackers@arkaria.postgresql.org; Sat, 09 Feb 2019 15:56:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gsUzS-0008UN-H5 for pgsql-hackers@arkaria.postgresql.org; Sat, 09 Feb 2019 15:56:26 +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 1gsUzS-0008UG-6o for pgsql-hackers@lists.postgresql.org; Sat, 09 Feb 2019 15:56:26 +0000 Received: from mail-qt1-x841.google.com ([2607:f8b0:4864:20::841]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gsUzK-00027q-5Z for pgsql-hackers@postgresql.org; Sat, 09 Feb 2019 15:56:25 +0000 Received: by mail-qt1-x841.google.com with SMTP id j36so7389499qta.7 for ; Sat, 09 Feb 2019 07:56:17 -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=qNtXJyxMAUiIy33bUq/sToEQqEbV7tvi4PB2AgLd++U=; b=BfiRBndctits6nl1Lbg8/fQzNLPa/3lwT7mkVLApmi0S44947jJ/8CpWvmaYY7uSLk gMKMZ7xNk3qYL8nLK0s7tv75tTPbn7RtgmsBxphfUqga6XO3ZVpZc2TDEghTc2tEYAlx Zqf0rD25Yx5AIHtSvp1H4NHncZjZeBjo69/5TDDTuylH74/6SBPHlz01Q5uZCwZkExfN GBxQg7yIbP/DXhtR9S501H0cGs41bmLsMDCiyTb+6pA6PpKJ5J10wuuM3r8bSAhJSWjV 8qUzFzpbOtDtfSs89O44MnDrReTMFbK7jYSvL2mpM4qry0Jqvn8jQ+Tb+ZQpVMSEVkB1 eCFA== 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=qNtXJyxMAUiIy33bUq/sToEQqEbV7tvi4PB2AgLd++U=; b=Lwyy2TwjOsWpFpOXhnA1I9o8IXRIfNpd8pC3X0FAIohUgUJk9ARyQYp4gQFdcECdNZ Drr1PkXbirx9xH8bYsS69WLGVdnspLW4quzyoJgDix9bQAdPab+36mNQ9Bk7XXSweQTW b4xT5yp30vd8GRe+xHoUEACSS4c+ZlHBvgOv7zEbxpJBd/CgHNpJHhrlynu0DWWxwouI ZlYrU9Albg9MSNGCJNI5x2FSIIRPrcyraC8G8sl/mTLvVDl+arc7owIJj29gnqzyj6UA uMatx50Ln9HDfzKeX8RfUZYsivGj/z2DQ2wETZb0Z/MBvxZtnSySVaOivi7RQX9qh/8s fISw== X-Gm-Message-State: AHQUAubJTTTblNWFp/0oMGY02/DSyrXhit66jdHk5iG8Fg2z3OeBqaPg 7lsw1G/jGIhyqqgk3R/Nn9vchw== X-Google-Smtp-Source: AHgI3IY6hRnm1YFa12AIdSzZpPaYUX1F+FpJBmonQI+yVdzMrXjoVxfD1jovHKF0d+u4k273SEJcVA== X-Received: by 2002:ac8:364e:: with SMTP id n14mr1164827qtb.285.1549727776025; Sat, 09 Feb 2019 07:56:16 -0800 (PST) Received: from nimloth.alvh.no-ip.org ([201.186.80.67]) by smtp.gmail.com with ESMTPSA id y33sm7045045qty.11.2019.02.09.07.56.14 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 09 Feb 2019 07:56:15 -0800 (PST) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id 3FB781245DA; Sat, 9 Feb 2019 12:56:13 -0300 (-03) Date: Sat, 9 Feb 2019 12:56:13 -0300 From: Alvaro Herrera To: Tom Lane Cc: Amit Langote , Peter Geoghegan , PostgreSQL Hackers Subject: Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages) Message-ID: <20190209155613.GA2091@alvherre.pgsql> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="/9DWx/yDrRhgMJTb" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <16446.1549697160@sss.pgh.pa.us> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit On 2019-Feb-09, Tom Lane wrote: > Amit Langote writes: > > On Sat, Feb 9, 2019 at 9:41 AM Tom Lane wrote: > >> +1. The best solution would presumably be to go through the normal > >> object deletion mechanism; though possibly there's a reason that > >> won't work given you're already inside some other DDL. > > > Maybe: > > - CatalogTupleDelete(trigrel, &trigtup->t_self); > > + RemoveTriggerById(trgform->oid)? > > No, that's still the back end of the deletion machinery, and in particular > it would fail to clean pg_depend entries for the trigger. Going in by the > front door would use performDeletion(). (See deleteOneObject() to get > an idea of what's being possibly missed out here.) This patch I think does the right thing. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services --/9DWx/yDrRhgMJTb Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="fix-trigger-drop.patch" commit 7031ce2b1f79a2e03b29ac896f0a008b0621d654 Author: Alvaro Herrera AuthorDate: Sat Feb 9 12:31:25 2019 -0300 CommitDate: Sat Feb 9 12:53:00 2019 -0300 fix trigger drop diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c index 910e5deaa3f..923866b7e11 100644 --- a/src/backend/commands/tablecmds.c +++ b/src/backend/commands/tablecmds.c @@ -8024,17 +8024,21 @@ CloneFkReferencing(Relation pg_constraint, Relation parentRel, while ((trigtup = systable_getnext(scan)) != NULL) { Form_pg_trigger trgform = (Form_pg_trigger) GETSTRUCT(trigtup); + ObjectAddress trigger; if (trgform->tgconstrrelid != fk->conrelid) continue; if (trgform->tgrelid != fk->confrelid) continue; - deleteDependencyRecordsForClass(TriggerRelationId, - HeapTupleGetOid(trigtup), - ConstraintRelationId, - DEPENDENCY_INTERNAL); - CatalogTupleDelete(trigrel, &trigtup->t_self); + deleteDependencyRecordsFor(TriggerRelationId, + HeapTupleGetOid(trigtup), + false); + /* make dependency deletion visible to performDeletion */ + CommandCounterIncrement(); + ObjectAddressSet(trigger, TriggerRelationId, + HeapTupleGetOid(trigtup)); + performDeletion(&trigger, DROP_RESTRICT, 0); } systable_endscan(scan); --/9DWx/yDrRhgMJTb--