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
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 |