Hi, Thanks for your comments!
On Sat, Jan 10, 2009 at 10:36 PM, Simon Riggs <si...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers