(2013/12/12 18:09), Simon Riggs wrote:
On 9 December 2013 10:54, KONDO Mitsumasa <kondo.mitsum...@lab.ntt.co.jp> wrote:
(2013/12/09 19:35), Pavel Stehule wrote:




2013/12/9 KONDO Mitsumasa <kondo.mitsum...@lab.ntt.co.jp
<mailto: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?

This is because local time is recorded in XLOG. And it has big cost for
calculating global time.

I agree with your request here, but I don't think negative values are
the right way to implement that, at least it would not be very usable.
I think that my proposal is the easiest and simplist way to solve this problem. And I believe that the man who cannot calculate the difference in time-zone doesn't set replication cluster across continents.

My suggestion would be to add the TZ to the checkpoint record. This
way all users of WAL can see the TZ of the master and act accordingly.
I'll do a separate patch for that.
It is something useful for also other situations. However, it might be
going to happen long and complicated discussions... I think that our hope is to commit this patch in this commit-fest or next final commit-fest.

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

Reply via email to