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.92) (envelope-from ) id 1j7nPO-000529-Ks for pgsql-hackers@arkaria.postgresql.org; Fri, 28 Feb 2020 21:42:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1j7nPN-0006GL-G6 for pgsql-hackers@arkaria.postgresql.org; Fri, 28 Feb 2020 21:42:57 +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 1j7nLO-0004fb-GM for pgsql-hackers@lists.postgresql.org; Fri, 28 Feb 2020 21:38:50 +0000 Received: from mail-yw1-xc44.google.com ([2607:f8b0:4864:20::c44]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1j7nLM-0007nB-8R for pgsql-hackers@lists.postgresql.org; Fri, 28 Feb 2020 21:38:49 +0000 Received: by mail-yw1-xc44.google.com with SMTP id t141so4736489ywc.11 for ; Fri, 28 Feb 2020 13:38:48 -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=W5SQTSJPoihsL1KRVcZrLuZhsPqcE8slhcwitM6r7r0=; b=sULaja7gr6IumAv6zngjlJ0z6L+ftjnGOpDVt37xPTTWNQQ8F7bFChThqud53FxCfd 8LuRlXQflghLB0F94D1JQrKEwMomblKViQRTn1ufVj5O8tjE96Sv2owg+dVzVg9k4y/p mmDZaMW72FuVwGVgUTP00bqJdO2HNklgcmTVvtJ2g6JHnB7Ydcc91wO8Dw+JYo0wCoEG kgMnip89iyV+GJrRn6mMd+I19w5DnDgOZnVaTB4WTEbBDeOj/CF0nRO49yagwkKsid7V Ihb0Yuchv+8IF6K9SZviDIstNE3+zod0xEywdvnWwSwlzS/bBVaHOxk10Mnb3UTUiGmQ wttg== 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=W5SQTSJPoihsL1KRVcZrLuZhsPqcE8slhcwitM6r7r0=; b=kg3NXe/i8MhxTXGQJwW5d0GGEaQ3Uh4AfY5zS9ww/9zPFg+riRCt2a/7PFyIhkosZF TcKFhjrSA4KASENagfInY6N2H340/Q983HbgtNDmOTqR1SXxQ+edwwC40HnmLRpS08Oa M5hohAXmO15GbJiiIKVwF18Sfd4arOnLEcWRiLirhVx3+xfh+Q9FwkmzJsRofXFR78oZ OPiM7VJ0X/7bg05wa3nT+QQySi++L3mtP6pTTkm0bSfxzebGWnYETmyKsuhi8sSahsAt QrTh2U0UxKJdR/CCMhnAu95Toap2NZfZaN+jrbw+07Wf9yqEFkOw3osw/7uol/yxZQqO QQFw== X-Gm-Message-State: APjAAAVcd5ePA7oMv9KhybQWNhAfttyPYoLkH0WmjFFstCcrVCbSgxLi vrb/03i2PrfAL6UgMyIDEjJEChvc3FmUpQ== X-Google-Smtp-Source: APXvYqzkSJdTR9qA7Z6l0U5zOJp3wEXHcdZzOCR8mwswk8cglm9mSSDhLdfaJm2XEzKgDOM/vJ+tpg== X-Received: by 2002:a25:b98b:: with SMTP id r11mr4608996ybg.295.1582925927639; Fri, 28 Feb 2020 13:38:47 -0800 (PST) Received: from nimloth.alvh.no-ip.org ([199.116.115.139]) by smtp.gmail.com with ESMTPSA id o13sm2656057ywl.9.2020.02.28.13.38.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 Feb 2020 13:38:47 -0800 (PST) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id 61058300651; Fri, 28 Feb 2020 10:44:51 -0300 (-03) Date: Fri, 28 Feb 2020 10:44:51 -0300 From: Alvaro Herrera To: ahsan hadi Cc: pgsql-hackers@lists.postgresql.org Subject: Re: more ALTER .. DEPENDS ON EXTENSION fixes Message-ID: <20200228134451.GA22878@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <158287616306.14910.17791108224723819457.pgcf@coridan.postgresql.org> 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-28, ahsan hadi wrote: > Tested the pg_dump patch for dumping "ALTER .. DEPENDS ON EXTENSION" in case of indexes, functions, triggers etc. The "ALTER .. DEPENDS ON EXTENSION" is included in the dump. However in some case not sure why "ALTER INDEX.....DEPENDS ON EXTENSION" is repeated several times in the dump? Hi, thanks for testing. Are the repeated commands for the same index, same extension? Did you apply the same command multiple times before running pg_dump? There was an off-list complaint that if you repeat the ALTER .. DEPENDS for the same object on the same extension, then the same dependency is registered multiple times. (You can search pg_depend for "deptype = 'x'" to see that). I suppose that would lead to the line being output multiple times by pg_dump, also. Is that what you did? If so: Patch 0002 is supposed to fix that problem, by raising an error if the dependency is already registered ... though it occurs to me now that it would be more in line with custom to make the command a silent no-op. In fact, doing that would cause old dumps (generated with databases containing duplicated entries) to correctly restore a single entry, without error. Therefore my inclination now is to change 0002 that way and push and backpatch it ahead of 0001. I realize just now that I have failed to verify what happens with partitioned indexes. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services