Re: pg_rewind in contrib

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>, Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Satoshi Nagayasu <snaga(at)uptime(dot)jp>, PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>, Michael Paquier <mpaquier(at)vmware(dot)com>
Subject: Re: pg_rewind in contrib
Date: 2015-01-09 08:48:39
Message-ID: 54AF95E7.20106@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2015-01-09 08:49:00 Re: INSERT ... ON CONFLICT UPDATE and RLS
Previous Message Dean Rasheed 2015-01-09 08:38:05 Re: Possible typo in create_policy.sgml