Re: pg_dump doesn't dump new objects created in schemas from extensions

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Martín Marqués <martin(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: pg_dump doesn't dump new objects created in schemas from extensions
Date: 2016-06-22 18:52:14
Message-ID: 20160622185213.GP21416@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> =?UTF-8?Q?Mart=c3=adn_Marqu=c3=a9s?= <martin(at)2ndquadrant(dot)com> writes:
> > On HEAD I actually see that we *are* setting dump_contains as well:
>
> > if (fout->remoteVersion < 90600)
> > dobj->dump = DUMP_COMPONENT_NONE;
> > else
> > dobj->dump = ext->dobj.dump_contains & (DUMP_COMPONENT_ACL |
> > DUMP_COMPONENT_SECLABEL | DUMP_COMPONENT_POLICY);
>
> Uh, what?
>
> (BTW, Stephen, what's the point of the version check here? The 'else'
> code seems like it would work just fine in all branches.)

We only have the pg_init_privs information in 9.6 and above. If we
dumped out extension ACLs, etc, for prior versions, we'd end up dumping
all of them (including ones which were set initially as part of the
extension itself). That didn't seem quite right.

Generally speaking, the checks are there to keep dumps of prior-to-9.6
versions of PG similar to pre-9.6 pg_dump.

> >> So maybe just moving the checkExtensionMembership call to after the other
> >> stuff would be enough in HEAD?
>
> > Looking into older versions as well I can't see how placing
> > checkExtensionMembership at the end of selectDumpableNamespace would
> > help. (like-wise for other selectDumpable's)
>
> The fix in HEAD will necessarily look quite a bit different from
> the back branches, I fear. But the idea I had in mind there was that
> we'd calculate a namespace's dump and dump_contains flags as if it
> were not an extension member, and then allow checkExtensionMembership
> to overwrite the dump flags if it is a member. Since
> checkExtensionMembership doesn't touch the dump_contains flags, that
> would leave all the flags in the desired state.

That sounds like a pretty reasonable idea. The devil is in the details
with pg_dump though, we'll definitely want a bunch of regression tests
around this to ensure we have the correct behavior, and notice if we
break it (as happened, apparently, in the back-branches already).

Thanks!

Stephen

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message juniorperezpy 2016-06-22 22:40:47 BUG #14209: Rules don't validate duplicated keys
Previous Message Maxim Sobolev 2016-06-22 18:49:33 Re: BUG #14206: Switch to using POSIX semaphores on FreeBSD