On Wednesday, October 10, 2012 9:15 PM Heikki Linnakangas wrote: > On 04.10.2012 13:12, Amit kapila wrote: > > Following changes are done to support replication timeout in sender as > well as receiver: > > > > 1. One new configuration parameter wal_receiver_timeout is added to > detect timeout at receiver task. > > 2. Existing parameter replication_timeout is renamed to > wal_sender_timeout. > > Ok. The other option would be to have just one GUC, I'm open to > bikeshedding on this one. On one hand, there's no reason the timeouts > have to the same, so it would be nice to have separate settings, but on > the other hand, I can't imagine a case where a single setting wouldn't > work just as well.
I think for below case, they are required to be separate: 1. M1 (Master), S1 (Standby 1), S2 (Standby 2) 2. S1 is standby for M1, and S2 is standby for S1. Basically a simple case of cascaded replication 3. M1 and S1 are on local network but S2 is placed at geographically different location. (what I want to say is n/w between M1-S1 is of good speed and S1-S2 is very slow) 4. In above case, user might want to configure different timeouts for sender and receiver on S1. > Attached is an updated patch. I reverted the merging of message types > and fixed a bunch of cosmetic issues. There was one bug: in the main > loop of walreceiver, you send the "ping" message on every wakeup after > enough time has passed since last reception. That means that if the > server doesn't reply promptly, you send a new ping message every 100 ms > (NAPTIME_PER_CYCLE), until it gets a reply. Walsender had the same > issue, but it was not quite as sever there because the naptime was > longer. Fixed that. Thanks. > > How does this look now? The Patch is fine and test results are also fine. With Regards, Amit Kapila. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
