Re: Re: BUG #6264: Superuser does not have inherent Replication permission

The following bug has been logged online:

Bug reference: 6264
Logged by: Keith Fiske
Email address: keith(at)omniti(dot)com
PostgreSQL version: 9.1.1
Operating system: Debian
Description: Superuser does not have inherent Replication permission
Details:

Was testing out an upgrade from 9.0.4 to 9.1.1 and ran across either some
lack of clarity in the documentation or a bug in the superuser privilege.
I had a streaming replication setup and after the upgrade and setting up the
new slave, the slave would no longer connect to the master for SR. Looking
into this more, I saw that 9.1 has a new Replication permission to allow
non-superusers the ability to be replication users.
The documentation says replication is inherent to a superuser. After testing
several times, I can assure you it is not. The old replication user from
9.0.4 which was carried through the upgrade kept its superuser privileges,
but was unable to be used for replication until I explicitly granted it the
Replication permission.
Brand new roles created initially as superusers are explicitly given the
separate replication permission. If you create a user as a NONsuperuser,
then later ALTER them to be one, they will NOT have the replication
permission and cannot be used as a replication user until you explicitly
grant that permission.

"Keith Fiske" <keith(at)omniti(dot)com> writes:
> The documentation says replication is inherent to a superuser.

What it actually says is that superusers get the replication privilege
by default --- but you can create a superuser without that. If you
see a place that says something different, please point it out
specifically so we can improve it.

> After testing
> several times, I can assure you it is not.

Please show your test case. It looks to me like it works as expected:

regression=# create user foo superuser;
CREATE ROLE
regression=# create user foo2 superuser noreplication;
CREATE ROLE
regression=# select rolname,rolsuper,rolreplication from pg_authid ;
rolname | rolsuper | rolreplication
----------+----------+----------------
postgres | t | t
foo | t | t
foo2 | t | f
(3 rows)

> If you create a user as a NONsuperuser,
> then later ALTER them to be one, they will NOT have the replication
> permission and cannot be used as a replication user until you explicitly
> grant that permission.

That doesn't sound to me like a bug. These flags are independent, we
just provide a certain default at role creation time.

regards, tom lane

On Sat, Oct 22, 2011 at 11:49 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Keith Fiske" <keith(at)omniti(dot)com> writes:
>> The documentation says replication is inherent to a superuser.
>
> What it actually says is that superusers get the replication privilege
> by default --- but you can create a superuser without that.  If you
> see a place that says something different, please point it out
> specifically so we can improve it.

From the documentation
"...If not specified, NOREPLICATION is the default for all roles
except superusers..."

From the 9.1 release notes:
"...Previously only superusers could initiate replication connections;
superusers still have this permission by default..."

Reading through all the other options, none of them state anything
special about superuser defaults. As stated above, if one were first
reading this, one would assume that a superuser would have replication
permission as default, no matter if it was given superuser via ALTER
ROLE or CREATE ROLE. If you're going to start saying which permissions
a superuser has and doesn't have by default, you should be consistent
with all of them and clearly state how and when they are given. Ex:
superusers inherently have CREATEROLE and CREATEDB, but not LOGIN.
And especially reading the release notes the use of the word "still"
would indicate that it works the same as it did in 9.0. It's what
caused my much of my confusion in this whole thing.

When I upgraded my 9.0.4 system to 9.1 and couldn't get streaming
replication to work, I saw the above and began to assume this was a
regression of the "replication" role name issue since it gave the same
error that that bug gave and things were working fine in 9.0.4. It was
only after I created a brand new superuser and then did a \du that I
noticed the replication permission was tacked on separately and only
during role creation. An upgrade from 9.0 to 9.1 does not account for
SR users and the release notes should probably reflect this, NOT state
that superusers still have the permission by default. They don't.

>
>> After testing
>> several times, I can assure you it is not.
>
> Please show your test case.  It looks to me like it works as expected:
>
> regression=# create user foo superuser;
> CREATE ROLE
> regression=# create user foo2 superuser noreplication;
> CREATE ROLE
> regression=# select rolname,rolsuper,rolreplication from pg_authid ;
>  rolname  | rolsuper | rolreplication
> ----------+----------+----------------
>  postgres | t        | t
>  foo      | t        | t
>  foo2     | t        | f
> (3 rows)
>
>

If you create a non-super user then ALTER them to be one, they don't
have replication as default. This either needs to be clarified in the
documentation or the ALTER should give the same defaults as the
CREATE. Whether it's inherent like CREATEDB or a separate permission,
I don't think matters and is a whole other argument. But things should
be consistent in some manner.

>> If you create a user as a NONsuperuser,
>> then later ALTER them to be one, they will NOT have the replication
>> permission and cannot be used as a replication user until you explicitly
>> grant that permission.
>
> That doesn't sound to me like a bug.  These flags are independent, we
> just provide a certain default at role creation time.
>

That is not what the documentation as read would lead people to
believe. I'd be more than happy to help with clarifying the
documentation myself if needed. Just let me know how.

>                        regards, tom lane
>

--
Keith Fiske
Database Administrator
OmniTI Computer Consulting, Inc.

On Mon, Oct 24, 2011 at 16:37, Keith Fiske <keith(at)omniti(dot)com> wrote:
> On Sat, Oct 22, 2011 at 11:49 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> "Keith Fiske" <keith(at)omniti(dot)com> writes:
>
>>> If you create a user as a NONsuperuser,
>>> then later ALTER them to be one, they will NOT have the replication
>>> permission and cannot be used as a replication user until you explicitly
>>> grant that permission.
>>
>> That doesn't sound to me like a bug.  These flags are independent, we
>> just provide a certain default at role creation time.
>>
>
> That is not what the documentation as read would lead people to
> believe. I'd be more than happy to help with clarifying the
> documentation myself if needed. Just let me know how.

This part I agree with - it makes sense for ALTER to set both flags
when it enables superuser. It seems inconsistent now - even if it may
be technically correct.

If we don't change it, we should definitely accept a docs patch to
clarify what happens, because I agree it's confusing.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

On Tue, Oct 25, 2011 at 1:39 PM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> On Mon, Oct 24, 2011 at 16:37, Keith Fiske <keith(at)omniti(dot)com> wrote:
>> On Sat, Oct 22, 2011 at 11:49 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> "Keith Fiske" <keith(at)omniti(dot)com> writes:
>>
>>>> If you create a user as a NONsuperuser,
>>>> then later ALTER them to be one, they will NOT have the replication
>>>> permission and cannot be used as a replication user until you explicitly
>>>> grant that permission.
>>>
>>> That doesn't sound to me like a bug.  These flags are independent, we
>>> just provide a certain default at role creation time.
>>>
>>
>> That is not what the documentation as read would lead people to
>> believe. I'd be more than happy to help with clarifying the
>> documentation myself if needed. Just let me know how.
>
> This part I agree with - it makes sense for ALTER to set both flags
> when it enables superuser.

+1

Change the behaviour to match the docs makes most sense to me.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

On Tue, Oct 25, 2011 at 8:39 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> On Mon, Oct 24, 2011 at 16:37, Keith Fiske <keith(at)omniti(dot)com> wrote:
>> On Sat, Oct 22, 2011 at 11:49 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> "Keith Fiske" <keith(at)omniti(dot)com> writes:
>>
>>>> If you create a user as a NONsuperuser,
>>>> then later ALTER them to be one, they will NOT have the replication
>>>> permission and cannot be used as a replication user until you explicitly
>>>> grant that permission.
>>>
>>> That doesn't sound to me like a bug.  These flags are independent, we
>>> just provide a certain default at role creation time.
>>>
>>
>> That is not what the documentation as read would lead people to
>> believe. I'd be more than happy to help with clarifying the
>> documentation myself if needed. Just let me know how.
>
> This part I agree with - it makes sense for ALTER to set both flags
> when it enables superuser. It seems inconsistent now - even if it may
> be technically correct.
>
> If we don't change it, we should definitely accept a docs patch to
> clarify what happens, because I agree it's confusing.

There's a pre-existing catalog flag called rolcatupdate that works a
little bit like this, and we discussed making rolreplication behave
similarly. But we ended up with different semantics:

rhaas=# create user bob nosuperuser;
CREATE ROLE
rhaas=# create user fred nosuperuser;
CREATE ROLE
rhaas=# alter role fred superuser;
ALTER ROLE
rhaas=# create user harry superuser;
CREATE ROLE
rhaas=# select * from pg_authid where rolname in ('bob', 'fred',
'harry') order by rolname;
rolname | rolsuper | rolinherit | rolcreaterole | rolcreatedb |
rolcatupdate | rolcanlogin | rolreplication | rolconnlimit |
rolpassword | rolvaliduntil
---------+----------+------------+---------------+-------------+--------------+-------------+----------------+--------------+-------------+---------------
bob | f | t | f | f | f
| t | f | -1 | |
fred | t | t | f | f | t
| t | f | -1 | |
harry | t | t | f | f | t
| t | t | -1 | |
(3 rows)

One difference is that, AFAIK, there's no DDL command to change
rolcatupdate separately from rolsuper. If we do decide to change the
behavior, we'd better carefully document that if you want to make
someone a superuser without giving them replication privileges (or
revoke their superuser status without revoking replication
privileges), you need to specify both ALTER TABLE options.

All in all I'm somewhat inclined to think we should just patch the
docs. 9.1 hasn't been out for very long, so maybe expectations aren't
too settled yet, but changing security-critical behavior in back
branches doesn't seem like a wonderful idea; and I think I mildly
prefer the current semantics to the proposed ones.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> ... If we do decide to change the
> behavior, we'd better carefully document that if you want to make
> someone a superuser without giving them replication privileges (or
> revoke their superuser status without revoking replication
> privileges), you need to specify both ALTER TABLE options.

You'd also have to be careful about processing-order dependencies;
consider
ALTER USER joe NOREPLICATION SUPERUSER;
which would do the wrong thing with a naive implementation.

> All in all I'm somewhat inclined to think we should just patch the
> docs. 9.1 hasn't been out for very long, so maybe expectations aren't
> too settled yet, but changing security-critical behavior in back
> branches doesn't seem like a wonderful idea; and I think I mildly
> prefer the current semantics to the proposed ones.

+1

regards, tom lane

On Thu, Oct 27, 2011 at 01:45:34PM -0400, Robert Haas wrote:
> On Tue, Oct 25, 2011 at 8:39 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> > On Mon, Oct 24, 2011 at 16:37, Keith Fiske <keith(at)omniti(dot)com> wrote:
> >> On Sat, Oct 22, 2011 at 11:49 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >>> "Keith Fiske" <keith(at)omniti(dot)com> writes:
> >>
> >>>> If you create a user as a NONsuperuser,
> >>>> then later ALTER them to be one, they will NOT have the replication
> >>>> permission and cannot be used as a replication user until you explicitly
> >>>> grant that permission.
> >>>
> >>> That doesn't sound to me like a bug. ?These flags are independent, we
> >>> just provide a certain default at role creation time.
> >>>
> >>
> >> That is not what the documentation as read would lead people to
> >> believe. I'd be more than happy to help with clarifying the
> >> documentation myself if needed. Just let me know how.
> >
> > This part I agree with - it makes sense for ALTER to set both flags
> > when it enables superuser. It seems inconsistent now - even if it may
> > be technically correct.
> >
> > If we don't change it, we should definitely accept a docs patch to
> > clarify what happens, because I agree it's confusing.
>
> There's a pre-existing catalog flag called rolcatupdate that works a
> little bit like this, and we discussed making rolreplication behave
> similarly. But we ended up with different semantics:

[ALTER ROLE sets rolcatupdate = rolsuper when changing rolsuper.]

> One difference is that, AFAIK, there's no DDL command to change
> rolcatupdate separately from rolsuper. If we do decide to change the
> behavior, we'd better carefully document that if you want to make
> someone a superuser without giving them replication privileges (or
> revoke their superuser status without revoking replication
> privileges), you need to specify both ALTER TABLE options.

Let's look at the behavior of DDL-exposed access constraints for precedent. We
currently have three paradigms for applying access control to superusers:

1. Settings that affect superusers and regular users identically. These include
ALTER ROLE ... LOGIN | VALID UNTIL.

2. Rights that superusers possess implicitly and irrevocably; the actual setting
recorded in pg_authid or elsewhere has no effect. These include GRANT ... ON
TABLE and ALTER ROLE ... CREATEDB | CREATEROLE.

3. ALTER ROLE ... REPLICATION is very similar to #1, except that CREATE ROLE
... SUPERUSER implies CREATE ROLE ... SUPERUSER REPLICATION.

I think we should merge #3 into #2; nothing about the REPLICATION setting
justifies a distinct paradigm. On a clean slate, #1 might be an equally
suitable fit. However, #2 provides better backward compatibility with 9.0.

> All in all I'm somewhat inclined to think we should just patch the
> docs. 9.1 hasn't been out for very long, so maybe expectations aren't
> too settled yet, but changing security-critical behavior in back
> branches doesn't seem like a wonderful idea; and I think I mildly
> prefer the current semantics to the proposed ones.

The implication of my proposal is to remove the possibility of creating a
superuser that cannot connect for replication; users so restricted under 9.1.1
would suddenly be able to make replication connections in 9.1.2. Of course,
they could already "ALTER ROLE myself REPLICATION". On that account, no secure
system would quietly become insecure following such an upgrade.

nm

Noah Misch <noah(at)leadboat(dot)com> writes:
> Let's look at the behavior of DDL-exposed access constraints for precedent. We
> currently have three paradigms for applying access control to superusers:

> 1. Settings that affect superusers and regular users identically. These include
> ALTER ROLE ... LOGIN | VALID UNTIL.

> 2. Rights that superusers possess implicitly and irrevocably; the actual setting
> recorded in pg_authid or elsewhere has no effect. These include GRANT ... ON
> TABLE and ALTER ROLE ... CREATEDB | CREATEROLE.

> 3. ALTER ROLE ... REPLICATION is very similar to #1, except that CREATE ROLE
> ... SUPERUSER implies CREATE ROLE ... SUPERUSER REPLICATION.

> I think we should merge #3 into #2; nothing about the REPLICATION setting
> justifies a distinct paradigm.

Yeah, there's much to be said for that. I thought the notion of a
privilege that superusers might not have was pretty bogus to start with.

rolcatupdate isn't a very good precedent to rely on because it's never
been documented or used to any noticeable extent, so there's no reason
to think that it provides a tested-and-accepted behavior.

regards, tom lane

On Thu, Oct 27, 2011 at 6:15 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Noah Misch <noah(at)leadboat(dot)com> writes:
>> Let's look at the behavior of DDL-exposed access constraints for precedent.  We
>> currently have three paradigms for applying access control to superusers:
>
>> 1. Settings that affect superusers and regular users identically.  These include
>> ALTER ROLE ... LOGIN | VALID UNTIL.
>
>> 2. Rights that superusers possess implicitly and irrevocably; the actual setting
>> recorded in pg_authid or elsewhere has no effect.  These include GRANT ... ON
>> TABLE and ALTER ROLE ... CREATEDB | CREATEROLE.
>
>> 3. ALTER ROLE ... REPLICATION is very similar to #1, except that CREATE ROLE
>> ... SUPERUSER implies CREATE ROLE ... SUPERUSER REPLICATION.
>
>> I think we should merge #3 into #2; nothing about the REPLICATION setting
>> justifies a distinct paradigm.
>
> Yeah, there's much to be said for that.  I thought the notion of a
> privilege that superusers might not have was pretty bogus to start with.
>
> rolcatupdate isn't a very good precedent to rely on because it's never
> been documented or used to any noticeable extent, so there's no reason
> to think that it provides a tested-and-accepted behavior.

That seems fine for 9.2, but I am still not in favor of changing the
behavior in back branches. This is not such a confusing behavior that
we can't document our way out of it.

(Hey, if SELECT .. ORDER BY .. FOR UPDATE can return rows out of order
and we can document our way out of that, this is small potatoes by
comparison.)

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Oct 27, 2011 at 6:15 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Noah Misch <noah(at)leadboat(dot)com> writes:
>>> I think we should merge #3 into #2; nothing about the REPLICATION setting
>>> justifies a distinct paradigm.

>> Yeah, there's much to be said for that. I thought the notion of a
>> privilege that superusers might not have was pretty bogus to start with.

> That seems fine for 9.2, but I am still not in favor of changing the
> behavior in back branches. This is not such a confusing behavior that
> we can't document our way out of it.

Agreed, changing it in a minor release would be a bad idea.

regards, tom lane

On Fri, Oct 28, 2011 at 09:32:30AM -0400, Robert Haas wrote:
> On Thu, Oct 27, 2011 at 6:15 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Noah Misch <noah(at)leadboat(dot)com> writes:
> >> Let's look at the behavior of DDL-exposed access constraints for precedent. ?We
> >> currently have three paradigms for applying access control to superusers:
> >
> >> 1. Settings that affect superusers and regular users identically. ?These include
> >> ALTER ROLE ... LOGIN | VALID UNTIL.
> >
> >> 2. Rights that superusers possess implicitly and irrevocably; the actual setting
> >> recorded in pg_authid or elsewhere has no effect. ?These include GRANT ... ON
> >> TABLE and ALTER ROLE ... CREATEDB | CREATEROLE.
> >
> >> 3. ALTER ROLE ... REPLICATION is very similar to #1, except that CREATE ROLE
> >> ... SUPERUSER implies CREATE ROLE ... SUPERUSER REPLICATION.
> >
> >> I think we should merge #3 into #2; nothing about the REPLICATION setting
> >> justifies a distinct paradigm.
> >
> > Yeah, there's much to be said for that. ?I thought the notion of a
> > privilege that superusers might not have was pretty bogus to start with.

> That seems fine for 9.2, but I am still not in favor of changing the
> behavior in back branches. This is not such a confusing behavior that
> we can't document our way out of it.
>
> (Hey, if SELECT .. ORDER BY .. FOR UPDATE can return rows out of order
> and we can document our way out of that, this is small potatoes by
> comparison.)

Quite so. Let's do it that way.

On Fri, Oct 28, 2011 at 11:42:38AM -0400, Noah Misch wrote:
> On Fri, Oct 28, 2011 at 09:32:30AM -0400, Robert Haas wrote:
> > On Thu, Oct 27, 2011 at 6:15 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > > Noah Misch <noah(at)leadboat(dot)com> writes:
> > >> Let's look at the behavior of DDL-exposed access constraints for precedent. ?We
> > >> currently have three paradigms for applying access control to superusers:
> > >
> > >> 1. Settings that affect superusers and regular users identically. ?These include
> > >> ALTER ROLE ... LOGIN | VALID UNTIL.
> > >
> > >> 2. Rights that superusers possess implicitly and irrevocably; the actual setting
> > >> recorded in pg_authid or elsewhere has no effect. ?These include GRANT ... ON
> > >> TABLE and ALTER ROLE ... CREATEDB | CREATEROLE.
> > >
> > >> 3. ALTER ROLE ... REPLICATION is very similar to #1, except that CREATE ROLE
> > >> ... SUPERUSER implies CREATE ROLE ... SUPERUSER REPLICATION.
> > >
> > >> I think we should merge #3 into #2; nothing about the REPLICATION setting
> > >> justifies a distinct paradigm.
> > >
> > > Yeah, there's much to be said for that. ?I thought the notion of a
> > > privilege that superusers might not have was pretty bogus to start with.
>
> > That seems fine for 9.2, but I am still not in favor of changing the
> > behavior in back branches. This is not such a confusing behavior that
> > we can't document our way out of it.
> >
> > (Hey, if SELECT .. ORDER BY .. FOR UPDATE can return rows out of order
> > and we can document our way out of that, this is small potatoes by
> > comparison.)
>
> Quite so. Let's do it that way.

Patch attached.

On 02.01.2012 21:46, Noah Misch wrote:
> On Fri, Oct 28, 2011 at 11:42:38AM -0400, Noah Misch wrote:
>> On Fri, Oct 28, 2011 at 09:32:30AM -0400, Robert Haas wrote:
>>> On Thu, Oct 27, 2011 at 6:15 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>> Noah Misch<noah(at)leadboat(dot)com> writes:
>>>>> Let's look at the behavior of DDL-exposed access constraints for precedent. ?We
>>>>> currently have three paradigms for applying access control to superusers:
>>>>
>>>>> 1. Settings that affect superusers and regular users identically. ?These include
>>>>> ALTER ROLE ... LOGIN | VALID UNTIL.
>>>>
>>>>> 2. Rights that superusers possess implicitly and irrevocably; the actual setting
>>>>> recorded in pg_authid or elsewhere has no effect. ?These include GRANT ... ON
>>>>> TABLE and ALTER ROLE ... CREATEDB | CREATEROLE.
>>>>
>>>>> 3. ALTER ROLE ... REPLICATION is very similar to #1, except that CREATE ROLE
>>>>> ... SUPERUSER implies CREATE ROLE ... SUPERUSER REPLICATION.
>>>>
>>>>> I think we should merge #3 into #2; nothing about the REPLICATION setting
>>>>> justifies a distinct paradigm.
>>>>
>>>> Yeah, there's much to be said for that. ?I thought the notion of a
>>>> privilege that superusers might not have was pretty bogus to start with.
>>
>>> That seems fine for 9.2, but I am still not in favor of changing the
>>> behavior in back branches. This is not such a confusing behavior that
>>> we can't document our way out of it.
>>>
>>> (Hey, if SELECT .. ORDER BY .. FOR UPDATE can return rows out of order
>>> and we can document our way out of that, this is small potatoes by
>>> comparison.)
>>
>> Quite so. Let's do it that way.
>
> Patch attached.

Thanks, committed to master.

Was there something that still needed to be done for the 9.1 docs? I'm
not sure what the conclusion on that was in the discussions back in October.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

On Sat, Jan 14, 2012 at 06:34:25PM +0200, Heikki Linnakangas wrote:
> On 02.01.2012 21:46, Noah Misch wrote:
>> On Fri, Oct 28, 2011 at 11:42:38AM -0400, Noah Misch wrote:
>>> On Fri, Oct 28, 2011 at 09:32:30AM -0400, Robert Haas wrote:
>>>> On Thu, Oct 27, 2011 at 6:15 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>>> Noah Misch<noah(at)leadboat(dot)com> writes:
>>>>>> Let's look at the behavior of DDL-exposed access constraints for precedent. ?We
>>>>>> currently have three paradigms for applying access control to superusers:
>>>>>
>>>>>> 1. Settings that affect superusers and regular users identically. ?These include
>>>>>> ALTER ROLE ... LOGIN | VALID UNTIL.
>>>>>
>>>>>> 2. Rights that superusers possess implicitly and irrevocably; the actual setting
>>>>>> recorded in pg_authid or elsewhere has no effect. ?These include GRANT ... ON
>>>>>> TABLE and ALTER ROLE ... CREATEDB | CREATEROLE.
>>>>>
>>>>>> 3. ALTER ROLE ... REPLICATION is very similar to #1, except that CREATE ROLE
>>>>>> ... SUPERUSER implies CREATE ROLE ... SUPERUSER REPLICATION.
>>>>>
>>>>>> I think we should merge #3 into #2; nothing about the REPLICATION setting
>>>>>> justifies a distinct paradigm.
>>>>>
>>>>> Yeah, there's much to be said for that. ?I thought the notion of a
>>>>> privilege that superusers might not have was pretty bogus to start with.
>>>
>>>> That seems fine for 9.2, but I am still not in favor of changing the
>>>> behavior in back branches. This is not such a confusing behavior that
>>>> we can't document our way out of it.
>>>>
>>>> (Hey, if SELECT .. ORDER BY .. FOR UPDATE can return rows out of order
>>>> and we can document our way out of that, this is small potatoes by
>>>> comparison.)
>>>
>>> Quite so. Let's do it that way.
>>
>> Patch attached.
>
> Thanks, committed to master.

Thanks.

> Was there something that still needed to be done for the 9.1 docs? I'm
> not sure what the conclusion on that was in the discussions back in
> October.

Not that I noted. The former docs describe the 9.1 behavior thoroughly.