Re: pg_rewind in contrib

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: pg_rewind in contrib
Дата
Msg-id 54AF95E7.20106@vmware.com
обсуждение исходный текст
Ответ на Re: pg_rewind in contrib  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: pg_rewind in contrib  (Peter Eisentraut <peter_e@gmx.net>)
Re: pg_rewind in contrib  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
On 01/08/2015 10:44 PM, Peter Eisentraut wrote:
> On 1/6/15 7:17 PM, Andres Freund wrote:
>>> One problem is that it doesn't use the replication protocol,
>>>> so the setup is going to be inconsistent with pg_basebackup.  Maybe the
>>>> replication protocol could be extended to provide the required data.
>> I'm not particularly bothered by the requirement of also requiring a
>> normal, not replication, connection. In most cases that'll already be
>> allowed.
>
> I don't agree.  We have separated out replication access, especially in
> pg_hba.conf and with the replication role attribute, for a reason.  (I
> hope there was a reason; I don't remember.)  It is not unreasonable to
> set things up so that non-replication access is only from the
> application tier, and replication access is only from within the
> database tier.

I agree. A big difference between a replication connection and a normal 
database connection is that a replication connection is not bound to any 
particular database. It also cannot run transactions, and many other things.

It would nevertheless be handy to be able to do more stuff in a 
replication connection. For example, you might want to run functions 
like pg_create_restore_point(), pg_xlog_replay_pause/resume etc. in a 
replication connection. We should extend the replication protocol to 
allow such things. I'm not sure what it would look like; we can't run 
arbitrary queries when not being connected to a database, or arbitrary 
functions, but there are a lot of functions that would make sense.

> Now I understand that making pg_rewind work over a replication
> connection is a lot more work, and maybe we don't want to spend it, at
> least right now.  But then we either need to document this as an
> explicit deficiency and think about fixing it later, or we should
> revisit how replication access control is handled.

Right, that's how I've been thinking about this. I don't want to start 
working on the replication protocol right now, I think we can live with 
it as it is, but it sure would be nicer if it worked over a replication 
connection.

- Heikki




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: INSERT ... ON CONFLICT UPDATE and RLS
Следующее
От: Dean Rasheed
Дата:
Сообщение: Re: INSERT ... ON CONFLICT UPDATE and RLS