Re: max_standby_delay considered harmful

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: max_standby_delay considered harmful
Date: 2010-05-05 18:33:33
Message-ID: AANLkTilYFXPV49pMsMNetPXetTP4COx6g96UfnBWrLib@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, May 5, 2010 at 12:30 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> Robert Haas wrote:
>> Does my proposal (upthread) to limit this by quantity of WAL rather
>> than time have any legs, or is that impractical and/or otherwise poor?
>
> That would certainly be easier to implement sanely than a time-based
> quantity. One problem is that we don't know how much unapplied WAL there
> is, when you're not using streaming replication.

Hmm, that's a problem, likely fatally so.

> And I'm not sure how
> useful that is to users - it's very hard to estimate what to set it to.

I'm not sure whether that's really an issue or not. I mean, if we say
that the standby is allowed to be, say, 16MB behind the master, we
know that recovery time is bounded by how long it takes to replay
16MB. Which is in some ways more defined than saying we're behind the
primary by 30 min, which could take a long time to replay or not much
at all. But, I guess it's moot.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2010-05-05 18:39:26 Re: pg_migrator to /contrib in a later 9.0 beta
Previous Message Tom Lane 2010-05-05 17:41:31 Upcoming back-branch updates