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

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> Actually, I think that code is not just under-tested but poorly thought
>> out. It will dump ALL roles from a pre-9.5 database with NOBYPASSRLS;
>> even superusers.

> Superusers are always considered to have it, regardless of if the option
> is set for them and so, no, it isn't relevant to superusers (that's true
> for nearly all of the role attribute options, as I recall..).

OK, good.

> It can be
> reworked to set it for superusers when it's dumped, but I'm not sure
> that really helps. Consider that creating a new superuser role doesn't
> go and set CREATEROLE or any of the other attributes, yet a superuser is
> considered to have those rights regardless.

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;

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.

regards, tom lane