Re: Segmentation fault in pg_dumpall from master down to 9.1 and other bug introduced by RLS

On Thu, Nov 13, 2014 at 08:24:36PM -0500, Stephen Frost wrote:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> > What's bothering me is that I see this in pg_dumpall output from a 9.4
> > or earlier database:
> >
> > ALTER ROLE postgres WITH SUPERUSER INHERIT CREATEROLE CREATEDB LOGIN REPLICATION NOBYPASSRLS;
>
> Ah, yeah, good point.
>
> > That means that if you do a pg_upgrade from a 9.4 database, your built-in
> > superuser will now not have rolbypassrls set, though it does in a database
> > built in any other way. Even if that doesn't have any functional effect,
> > it's a recipe for confusion IMO. So I think that the code ought to be
> > "usesuper as rolbypassrls" rather than "false as rolbypassrls" for
> > back branches.
> >
> > The only other similar case is rolreplication, which perhaps also ought
> > to read as usesuper for old branches.
>
> Agreed. I'll take care of both and we'll make sure the new role
> attributes being added will do the same for upgrades also.

That would make pg_dumpall less faithful for every role other than the
bootstrap superuser, a net loss. It would be defensible to do this for
BOOTSTRAP_SUPERUSERID only. Even there I prefer the current behavior; this is
just another of many fine details that pg_upgrade reproduces more precisely
than other pg_dumpall/pg_dump invocations.