Re: Time-Delayed Standbys
От | Andres Freund |
---|---|
Тема | Re: Time-Delayed Standbys |
Дата | |
Msg-id | 20131210093848.GG27840@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: Time-Delayed Standbys (KONDO Mitsumasa <kondo.mitsumasa@lab.ntt.co.jp>) |
Ответы |
Re: Time-Delayed Standbys
|
Список | pgsql-hackers |
On 2013-12-10 13:26:27 +0900, KONDO Mitsumasa wrote: > (2013/12/09 20:29), Andres Freund wrote: > >On 2013-12-09 19:51:01 +0900, KONDO Mitsumasa wrote: > >>Add my comment. We have to consider three situations. > >> > >>1. PITR > >>2. replication standby > >>3. replication standby with restore_command > >> > >>I think this patch cannot delay in 1 situation. > > > >Why? > > I have three reasons. None of these reasons seem to be of technical nature, right? > 1. It is written in document. Can we remove it? > 2. Name of this feature is "Time-delayed *standbys*", not "Time-delayed > *recovery*". Can we change it? I don't think that'd be a win in clarity. But perhaps somebody else has a better suggestion? > 3. I think it is unnessesary in master PITR. And if it can delay in master > PITR, it will become master at unexpected timing, not to continue to > recovery. It is meaningless. "master PITR"? What's that? All PITR is based on recovery.conf and thus not really a "master"? Why should we prohibit using this feature in PITR? I don't see any advantage in doing so. If somebody doesn't want the delay, they shouldn't set it in the configuration file. End of story. There's not really a that meaningful distinction between PITR and replication using archive_command. Especially when using *pause_after. I think this feature will be used in a lot of scenarios in which PITR is currently used. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: