From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Tomonari Katsumata <t(dot)katsumata1122(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: dividing privileges for replication role. |
Date: | 2013-01-21 02:32:24 |
Message-ID: | CAB7nPqRsSpQtQMhu-m5e7e3vA8ChaEUQUET4WMYtu_=9oNBd2g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jan 19, 2013 at 12:47 PM, Tomonari Katsumata <
t(dot)katsumata1122(at)gmail(dot)com> wrote:
> a) adding new privileges for replication:"MASTER REPLICATION" and "CASCADE
> REPLICATION"
>
> "MASTER REPLICATION": Replication-connection to master server is only
> allowed
> "CASCADE REPLICATION": Replication-connection to cascade server is only
> allowed
> ("REPLICATION" already implemented means replication-connection to both
> servers is allowed)
>
This does not really solve the case you reported because, as reported in
your bug, you could still have each slave connecting to each other using
the privilege CASCADE REPLICATION. It makes even the privilege level more
complicated.
What would be necessary to solve your problem would be to have each standby
being aware that it is connected to a unique master. This is not really an
issue with privileges but more of something like having a standby scanning
its upper cluster node tree and check if there is a master connected. While
checking the cluster node tree, you will also need to be aware if a node
has already been found when you scanned it to be sure that the same node
has not been scanned, what would mean that you are in a cycle.
--
Michael Paquier
http://michael.otacoo.com
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2013-01-21 02:37:32 | Re: CF3+4 (was Re: Parallel query execution) |
Previous Message | Craig Ringer | 2013-01-21 02:23:33 | Re: Contrib PROGRAM problem |