-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 12 Dec 2007 23:08:35 -0800 "Joshua D. Drake" <jd@xxxxxxxxxxxxxxxxx> wrote: > Tom Lane wrote: > > "Joshua D. Drake" <jd@xxxxxxxxxxxxxxxxx> writes: > >> Tom Lane wrote: > >>> You sure about that? I tested CVS HEAD just now, by setting the > >>> checkpoint_ parameters really high, > > > >> ... And: > > > >>> 2007-12-13 00:55:20 EST LOG: restored log file > >>> "00000001000007E10000006B" from archive > > > > Hmm --- I was testing a straight crash-recovery scenario, not > > restoring from archive. Are you sure your restore_command script > > isn't responsible for a lot of the delay? > > Now that's an interesting thought, I will review in the morning when > I have some more IQ points back. As promised :)... I took a look at this today and I think I found a couple of things. It appears that once the logs are archived, the recovery command copies the archive file to a recovery location and then restores the file. If that is correct that could explain some of the latency I am seeing here. Even with the speed of these devices, it is still a 16 MB file. That could take 1-2 seconds to copy. There is also the execution of pg_standby each time as the recovery command which although I haven't timed is going to add overhead. Based on the logs I pasted we are showing a delay of 6, 14, 3, 13, 4 and then another 6 seconds. When are fsyncs called on the recovery process? At these types of delays even speeding the process 2 seconds per log is going to be significant. Sincerely, Joshua D. Drake - -- The PostgreSQL Company: Since 1997, http://www.commandprompt.com/ Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate SELECT 'Training', 'Consulting' FROM vendor WHERE name = 'CMD' -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHYYQaATb/zqfZUUQRAiiNAKCNDaO+MYDDLM/lUbL4D9Q9NIEyRQCgqhye cJ2PAv9rEzAi/jDFPzzoFNw= =xNMz -----END PGP SIGNATURE----- ---------------------------(end of broadcast)---------------------------TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your message can get through to the mailing list cleanly
