Skip site navigation (1) Skip section navigation (2)

Re: BUG #7803: Replication Problem(no master is there)

From: Tomonari Katsumata <katsumata(dot)tomonari(at)po(dot)ntts(dot)co(dot)jp>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #7803: Replication Problem(no master is there)
Date: 2013-01-16 05:48:41
Message-ID: 50F63F39.7080306@po.ntts.co.jp (view raw or flat)
Thread:
Lists: pgsql-bugs
Hi,

(2013/01/16 4:03), Fujii Masao wrote:
 > On Tue, Jan 15, 2013 at 5:25 PM, Heikki Linnakangas
 > <hlinnakangas(at)vmware(dot)com> wrote:
 >> On 15.01.2013 10:14, Simon Riggs wrote:
 >>>
 >>> On 15 January 2013 05:12, Tomonari Katsumata
 >>> <katsumata(dot)tomonari(at)po(dot)ntts(dot)co(dot)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




In response to

pgsql-bugs by date

Next:From: Abhijit Menon-SenDate: 2013-01-16 07:48:17
Subject: Re: Review of "pg_basebackup and pg_receivexlog to use non-blocking socket communication", was: Re: Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown
Previous:From: Magnus HaganderDate: 2013-01-15 21:35:36
Subject: Re: BUG #7809: Running pg_dump on slave w/ streaming replication fails if there are unlogged tables

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group