Re: Fwd: Re: New 8.4 hot standby feature

From: Gabi Julien <gabi(dot)julien(at)broadsign(dot)com>
To: pgsql-general(at)postgresql(dot)org
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>
Subject: Re: Fwd: Re: New 8.4 hot standby feature
Date: 2009-01-28 19:20:56
Message-ID: 200901281420.56496.gabi.julien@broadsign.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Ivan Sergio Borgonovo 2009-01-28 20:14:24 Re: very long update gin index troubles back?
Previous Message Alban Hertroys 2009-01-28 18:25:09 Re: Slow first query despite LIMIT and OFFSET clause