Hi, On Mon, Jan 12, 2009 at 1:10 AM, Simon Riggs <si...@2ndquadrant.com> wrote: >> > 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. > > If we want multiple standby servers they wouldn't both be able to trim > files from the archive. So we would need to change pg_standby so it > records the %R from multiple servers on the archive and only trimmed the > max of those %R values.
s/max/min ? >> > 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? > > Sending takes time as well, so it is send_time + delay at least. Right. I'll change the doc into an exact description. Similarly, though the document of "synchronous_commit" says ----------- When off, there can be a delay between when success is reported to the client and when the transaction is really guaranteed to be safe against a server crash. (The maximum delay is three times wal_writer_delay.) ----------- write_time also should be added up to the maximum delay. >> > 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? > > May as well leave it in, so people can use it with 8.3. I'd like this patch to be reviewed and committed for 8.4 even if synch-rep is postponed to 8.5. Because this is very useful for existing warm-standby mechanism, and only warm-standby would be still a built-in replication solution in 8.4. 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
