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

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Tomonari Katsumata <katsumata(dot)tomonari(at)po(dot)ntts(dot)co(dot)jp>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #7803: Replication Problem(no master is there)
Date: 2013-01-15 19:03:39
Message-ID: CAHGQGwGsGoi8xgRC+9XDPqpLNmzwunY+=iuchxEjM10m6zZQew@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

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.
>
> 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).

> 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".

Regards,

--
Fujii Masao

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2013-01-15 19:13:51 Re: BUG #7811: strlen(NULL) cause psql crash
Previous Message Heikki Linnakangas 2013-01-15 19:01:13 Re: BUG #7811: strlen(NULL) cause psql crash