Re: more ALTER .. DEPENDS ON EXTENSION fixes

From: Ahsan Hadi <ahsan(dot)hadi(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: more ALTER .. DEPENDS ON EXTENSION fixes
Date: 2020-03-02 07:45:13
Message-ID: CA+9bhCLdPQBRDbqBr5Pux9_q7ubz5UtGRzh7sN92tp1NJzmFAA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Feb 29, 2020 at 2:38 AM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
wrote:

> 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?

Yes same index and same extension...

> Did you
> apply the same command multiple times before running pg_dump?
>

Yes but in some cases I applied the command once and it appeared multiple
times in the 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?
>

I checked out pg_depend for "deptype='x'" the same dependency is registered
multiple times...

>
> 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.
>

Makes sense, will also try our Patch 0002.

>
> I realize just now that I have failed to verify what happens with
> partitioned indexes.
>

Yes I also missed this one..

>
> --
> Álvaro Herrera https://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>

--
Highgo Software (Canada/China/Pakistan)
URL : http://www.highgo.ca
ADDR: 10318 WHALLEY BLVD, Surrey, BC
EMAIL: mailto: ahsan(dot)hadi(at)highgo(dot)ca

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2020-03-02 07:49:15 Re: [BUG?] postgres_fdw incorrectly updates remote table if it has inherited children.
Previous Message Arseny Sher 2020-03-02 07:41:54 Re: ERROR: subtransaction logged without previous top-level txn record