Hi,
Thanks for your comments!
On Sat, Jan 10, 2009 at 10:36 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> I notice we use the same settings for keepalives. We may need that to be
> a second set of parameters.
Or, we should make walreceiver execute "SET tcp_keepalives_xxx TO yyy"
before starting replication if such settins are specified in recovery.conf?
> Don't understand: "Completely automated catching up; User has to carry
> out some procedure manually for making the standby catch up."
Oh sorry, this description is not correct; the standby can catch up with the
primary automatically if archive area is shared between those two servers.
In fact, xlogs generated before / during replication are shipped by
archiver / walsender, respectively.
I also updated the figures about flow of xlogs. Please check it.
http://wiki.postgresql.org/wiki/NTT%27s_Development_Projects#Architecture_Design
> Multiple standby is still possible, but just using old file based
> mechanisms. We would need to be careful about use of %R in that case.
Yes. Synch Rep can work fine with existing warm-standby mechanism.
> I believe the max delay is 2* wal_sender_delay.
In async replication case, walsender tries to send the xlogs once per
wal_sender_delay, and receives the response from the standby on
demand. So, I think that max delay is wal_sender_delay. Am I missing
something?
> I like the way recovery_trigger_file avoids changing pg_standby, but I
> guess we still need to plug that gap also one day. But does patch 10
> also have the other mechanism?
As you imply, current synch-rep has already not needed the change
of pg_standby, so I'll get rid of the patch from synch-rep patchset.
Of course, this patch is still useful for existing warm-standby. I should
add this patch to commitfest for 8.5?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
