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
Re: pg_rewind in contrib |
| Список | 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 по дате отправления: