Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lqyg2-0008WU-PR for pgsql-hackers@arkaria.postgresql.org; Wed, 09 Jun 2021 13:55:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lqyg1-0001WJ-OO for pgsql-hackers@arkaria.postgresql.org; Wed, 09 Jun 2021 13:55:25 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lqyg1-0001WB-G3 for pgsql-hackers@lists.postgresql.org; Wed, 09 Jun 2021 13:55:25 +0000 Received: from wout1-smtp.messagingengine.com ([64.147.123.24]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lqyfv-0008Nl-3s for pgsql-hackers@lists.postgresql.org; Wed, 09 Jun 2021 13:55:25 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 83DB413F4; Wed, 9 Jun 2021 09:55:14 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 09 Jun 2021 09:55:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=Ul+mYlLXkXSJg03DM8KhOr88zJ0J/QG3OeR2hxo6vsE=; b=f6XXsq+5 Xsi7ZctcDDB1gURvQ2e6zMHEyE1J7egcu5kNdwoE8/wUSS1hIUWcwmZ8hb6NKB9J 9Mvz3FdMYJbFP3jEJQRq3TiU9vaXRbCtuPBM3h6p8mt0zXUBY6/D0YHmSVAK2ieX aC1dkM5jLyK7rPWlPLmmlVQeWpY5oQVnaPfmzXQ3CSHAvaWLBvwQl4xFYe/lpjWg RTOs80J2vFkTbWl5uS627QHoZsl5dyxH70ds7XRyHCrrEl/y6829WEalii+6CmVb EuxIKu0IgrJo3VxW5TkDwBp4IrNeoB2+wAaj7aQGcEnOLgKvfSbQ1JacKkzcNGQg D5UPPza+hGhb2Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeduuddgjedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfggtggugfgjsehtkeertddttddunecuhfhrohhmpeetlhhvrghr ohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgqe enucggtffrrghtthgvrhhnpeeggeevveffveejffdutefhvddtgeeghffhgfeuhfefjeei gfevhfefleevtdduteenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 9 Jun 2021 09:55:13 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 029F72A0A4D; Wed, 9 Jun 2021 09:55:09 -0400 (-04) Date: Wed, 9 Jun 2021 09:55:08 -0400 From: Alvaro Herrera To: Michael Paquier Cc: Aleksander Alekseev , PostgreSQL Hackers , Sven Klemm Subject: Re: Fix dropped object handling in pg_event_trigger_ddl_commands Message-ID: <202106091355.sphciftmvqds@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2021-Jun-09, Michael Paquier wrote: > On Mon, Jun 07, 2021 at 12:44:42PM +0300, Aleksander Alekseev wrote: > > I confirm that the bug still exists in master (be57f216). The patch > > fixes it and looks good to me. I changed the wording a little and > > added a regression test. The updated patch is in the attachment. I > > added this thread to the CF and updated the status to "Ready for > > Committer". > > FWIW, that looks rather natural to me to me to just ignore the object > if it has already been dropped here. The same kind of rules apply to > tables dropped with DROP TABLE which would not show up as of > pg_event_trigger_ddl_commands(), but one can get a list as of > pg_event_trigger_dropped_objects(). Oh, that parallel didn't occur to me. I agree it seems a useful precedent. > Alvaro, were you planning to look at that? I have not looked at the > patch in details. I have it on my list of things to look at, but it isn't priority. If you to mess with it, please be my guest. > missing_ok is available in getObjectIdentity() only > since v14, so this cannot be backpatched :/ Ooh, yeah, I forgot about that. And that one was pretty invasive ... I'm not sure if we can reasonably implement a fix for older releases. I mean, it's a relatively easy test: do a syscache search for the object or a catalog indexscan (easy to do with get_object_property_data-based API), and if the object is gone, skip getObjectTypeDescription and getObjectIdentity. But maybe this is too much code to add to stable releases ... -- Álvaro Herrera Valdivia, Chile