Re: pg_dump broken for non-super user

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > - USERMAP
>
> > Uses pg_options_to_table(), but I don't think that actually uses
> > SysCache at all, it's just taking the array provided and builds a
> > table out of it, so I think this case is ok.
>
> USERMAP seems a bit squishy and easily broken, perhaps. Not sure there's
> an advantage to distinguishing this case --- why did you break it out
> from DEFINITION to start with? Also, AFAICS, it does not apply to tables
> which are the only things we lock anyway.

When it comes to usermaps, they're dumped as part of FOREIGN SERVERs, so
I broke out the usermap as being an independent component from the
definition of the FOREIGN SERVER itself. I realize we don't currently
have a way to ask pg_dump to exclude user mappings, but it seemed like
it wouldn't be unreasonable for us to have that in the future as user
mappings include role names and we have similar options for avoiding
specific role names in a dump (eg: --no-owner).

I agree that there's nothing to lock for usermaps though, as they aren't
associated with tables.

> Seems reasonable otherwise.

Ok, I'll write up a patch for that, should be pretty trivial.

> > Of course, the pg_dump would still end up including the ACLs for
> > pg_authid and whatever other tables the user has changed the ACLs on and
> > errors will be thrown during restore if the restore is done with a
> > non-superuser.
>
> Right, but at least you have the option of ignoring such errors.

Agreed.

Thanks!

Stephen