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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
