Re: BUG #7803: Replication Problem(no master is there) - Mailing list pgsql-bugs

Hi,

(2013/01/16 4:03), Fujii Masao wrote:
 > On Tue, Jan 15, 2013 at 5:25 PM, Heikki Linnakangas
 > <hlinnakangas@vmware.com> wrote:
 >> On 15.01.2013 10:14, Simon Riggs wrote:
 >>>
 >>> On 15 January 2013 05:12, Tomonari Katsumata
 >>> <katsumata.tomonari@po.ntts.co.jp>  wrote:
 >>>
 >>>>> We added a REPLICATION privelge onto user accounts to control access.
 >>>>>
 >>>>> Perhaps we should add a CASCADE privilege as well, so that we can
 >>>>> control whether we can connect to a master and/or a standby.
 >>>>>
 >>>>> Syntax would be
 >>>>>
 >>>>> ALTER USER foo
 >>>>> [MASTER | CASCADE] REPLICATION
 >>>>>
 >>>>> REPLICATION allows both master and cascaded replication (same as now)
 >>>>> MASTER REPLICATION allows master only
 >>>>> CASCADE REPLICATION allows cascaded replication only
 >>>>> NOREPLICATION allows neither option
 >>>>>
 >>>
 >>>> Someone is working for it already ?
 >>>> If not yet, may I try to implement it ?
 >>>
 >>>
 >>> Please do. It looks fairly short.
 >>
 >>
 >> To me, permissions doesn't feel like the right vehicle for
controlling this.
 >> Not sure what to suggest instead, a new GUC perhaps.
 >>

If this is before releasing 9.2.0, it is not problem to have a new GUC.
But 9.2 has released already.

I'm thinking about this change is for 9.3, right ?

And I'm thinking about compatibility when version up too.
If we control this with permissions, I think it is easy to
upgrade from 9.1 and 9.2 to 9.3 using pg_upgrade/pg_dumpall.

Type of pg_authid.rolreplication is boolean.
---------------------------------------------------------------------
9.1 false(f=0)         true(t=1)
9.2 false(f=0)         true(t=1)
---------------------------------------------------------------------

If I add permissions for cascading replication,
it will become integer and represent each permission like this:
---------------------------------------------------------------------
9.3 noreplication(0) replication(1)  master-only(2)  cascade-only(3)
---------------------------------------------------------------------

If pg_upgrade/pg_dumpall handle like bellow, user would never mind about
difference between versions.

from 9.1 to 9.3.
   false(f=0) --> noreplication(0)
   true(t=1)  --> master-only(2)

from 9.2 to 9.3.
   false(f=0) --> noreplication(0)
   true(t=1)  --> replication(1)


 >> BTW, is there any reason to not allow streaming replication when
 >> hot_standby=off? A streaming replication connection doesn't execute any
 >> queries, so it doesn't need the system to be consistent.
 >
 > I was thinking that the system must be consistent since streaming
replication
 > connection reads the system catalog (e.g., ROLE information).
 >
And I think it's because replication connection is established
by same way with another backend connection.

 >> Another thing to consider is that "pg_basebackup -X stream" also uses
 >> streaming replication, so if you forbid cascade replication, you
also forbid
 >> using "pg_basebackup -X stream" on the standby. At the protocol level,
 >> pg_basebackup streams the WAL just like a standby server does, so we
cannot
 >> distinguish those two cases in the server. The client could tell the
server
 >> which one it is, but using permissions to allow/forbid based on that
would
 >> make no sense as the client could lie which one it is.
 >
 > Probably I'm missing something, but the standby server only has to
reject the
 > replication connection if cascade replication is disabled, whether
it's from
 > another standby or pg_basebackup. ISTM there is no need to distinguish
 > those connections. No?
 >
 > When "pg_basebackup -X stream" fails to establish the replication
connection,
 > it only has to just fail or automatically switch to "pg_basebackup -X
fetch".
 >
I think so too.
If user who does not have right permission executes "pg_basebackup -X
stream",
it would make fail.

regards,
--------
NTT Software Corporation
  Tomonari Katsumata