Re: Segmentation fault in pg_dumpall from master down to 9.1 and other bug introduced by RLS - Mailing list pgsql-hackers

From Noah Misch
Subject Re: Segmentation fault in pg_dumpall from master down to 9.1 and other bug introduced by RLS
Date
Msg-id 20141114034956.GA805521@tornado.leadboat.com
Whole thread Raw
In response to Re: Segmentation fault in pg_dumpall from master down to 9.1 and other bug introduced by RLS  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Re: Segmentation fault in pg_dumpall from master down to 9.1 and other bug introduced by RLS  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Nov 13, 2014 at 08:24:36PM -0500, Stephen Frost wrote:
> * Tom Lane (tgl@sss.pgh.pa.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.



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pg_basebackup vs. Windows and tablespaces
Next
From: Fujii Masao
Date:
Subject: Re: Unintended restart after recovery error