Re: pg_dump with tables created in schemas created by extensions - Mailing list pgsql-hackers

From Martín Marqués
Subject Re: pg_dump with tables created in schemas created by extensions
Date
Msg-id CAPdiE1wsPn-yko6NvoixWKh2P=ReMv=u=a+-saxLnDscFUFk2w@mail.gmail.com
Whole thread Raw
In response to Re: pg_dump with tables created in schemas created by extensions  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: pg_dump with tables created in schemas created by extensions  (Martín Marqués <martin@2ndquadrant.com>)
List pgsql-hackers
Hi,

2016-08-25 8:10 GMT-03:00 Michael Paquier <michael.paquier@gmail.com>:
> On Thu, Aug 25, 2016 at 10:25 AM, Martín Marqués <martin@2ndquadrant.com> wrote:
>> 2016-08-24 21:34 GMT-03:00 Michael Paquier <michael.paquier@gmail.com>:
>>>
>>> Yes, you are right. If I look at the diffs this morning I am seeing
>>> the ACLs being dumped for this aggregate. So we could just fix the
>>> test and be done with it. I did not imagine the index issue though,
>>> and this is broken for some time, so that's not exclusive to 9.6 :)
>>
>> Do you see any easier way than what I mentioned earlier (adding a
>> selectDumpableIndex() function) to fix the index dumping issue?
>
> Yes, we are going to need something across those lines. And my guess
> is that this is going to be rather close to getOwnedSeqs() in terms of
> logic.

I was able to get this fixed without any further new functions (just
using the dump/dump_contains and applying the same fix on
selectDumpableTable).

Main problem relied here in getIndexes()

@@ -6158,7 +6167,7 @@ getIndexes(Archive *fout, TableInfo tblinfo[],
int numTables)
                        continue;

                /* Ignore indexes of tables whose definitions are not
to be dumped */
-               if (!(tbinfo->dobj.dump & DUMP_COMPONENT_DEFINITION))
+               if (!(tbinfo->dobj.dump_contains & DUMP_COMPONENT_DEFINITION))
                        continue;

                if (g_verbose)

But we have to set dump_contains with correct values.

There's still one issue, which I'll add a test for as well, which is
that if the index was created by the extension, it will be dumped
anyway. I'll ave a look at that as well.

One other thing I found was that one of the CREATE INDEX tests had
incorrectly set like and unlike for pre_data and post_data. (indexes
are dumped in section post_data)

That's been fixes as well.

I've cleaned up the patch a bit, so this is v3 with all checks passing.

I'll add that new test regarding dumping an index created by the
extension (which will fail) and look for ways to fix it.

Regards,

--
Martín Marqués                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Attachment

pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Odd oid-system-column handling in postgres_fdw
Next
From: Alvaro Herrera
Date:
Subject: Re: WAL consistency check facility