On Tuesday 27 January 2009 16:25:44 you wrote: > On Tue, 2009-01-27 at 14:28 -0500, Gabi Julien wrote: > > Could this help? If the logs are smaller then I could potentially afford > > shipping then at a higher frequency. > > See if there are times during which the recovery process isn't doing > anything (i.e. just waiting for WAL data). If so, something like this > might help. If it's constantly working as hard as it can, then probably > not. > > An important question you should ask yourself is whether it can keep up > in the steady state at all. If the primary is producing segments faster > than the standby is recovering them, I don't think there's any way > around that.
The load on the slave is close to 0 so it does not explain the speed of recovery. Also the shipping of the 16MB WAL log takes only 1 second on the LAN. I guess the problem is probably what Fujii Masao explained. The WAL log shipped are not yet usable or something like that. I won't try to increase the frequency of log shipping because of that. Also, my setting of 60 seconds is the lowest frequency suggested by the documentation anyways. However, I have found the v4 patch about the PITR performance improvement. I will give it a try and report here. I might try pg_clearxlogtail too if I have time. > > Regards, > Jeff Davis -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
