2013/12/9 KONDO Mitsumasa <kondo.mitsum...@lab.ntt.co.jp> > Hi Fabrízio, > > I test your v4 patch, and send your review comments. > > * Fix typo > > 49 -# commited transactions from the master, specify a recovery time > delay. > > 49 +# committed transactions from the master, specify a recovery time > delay. > > * Fix white space > > 177 - if (secs <= 0 && microsecs <=0) > > 177 + if (secs <= 0 && microsecs <=0 ) > > * Add functionality (I propose) > We can set negative number at min_standby_apply_delay. I think that this > feature > is for world wide replication situation. For example, master server is in > Japan and slave server is in San Francisco. Japan time fowards than San > Francisco time > . And if we want to delay in this situation, it can need negative number > in min_standby_apply_delay. So I propose that time delay conditional branch > change under following. > > - if (min_standby_apply_delay > 0) > > + if (min_standby_apply_delay != 0) > What do you think? It might also be working collectry. >
what using interval instead absolute time? Regards Pavel > > > * Problem 1 > I read your wittened document. There is "PITR has not affected". > However, when I run PITR with min_standby_apply_delay=3000000, it cannot > start server. The log is under following. > >> [mitsu-ko@localhost postgresql]$ bin/pg_ctl -D data2 start >> server starting >> [mitsu-ko@localhost postgresql]$ LOG: database system was interrupted; >> last known up at 2013-12-08 18:57:00 JST >> LOG: creating missing WAL directory "pg_xlog/archive_status" >> cp: cannot stat `../arc/00000002.history': >> LOG: starting archive recovery >> LOG: restored log file "000000010000000000000041" from archive >> LOG: redo starts at 0/41000028 >> LOG: consistent recovery state reached at 0/410000F0 >> LOG: database system is ready to accept read only connections >> LOG: restored log file "000000010000000000000042" from archive >> FATAL: cannot wait on a latch owned by another process >> LOG: startup process (PID 30501) exited with exit code 1 >> LOG: terminating any other active server processes >> > We need recovery flag for controling PITR situation. > > > That's all for now. > If you are busy, please fix in your pace. I'm busy and I'd like to wait > your time, too:-) > > Regards, > -- > Mitsumasa KONDO > NTT Open Source Software Center > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
