Re: Keepalive for max_standby_delay - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Keepalive for max_standby_delay
Date
Msg-id AANLkTikg1F9EkmutcBZmcwH_TPntcugvvuG9VqfzGdve@mail.gmail.com
Whole thread Raw
In response to Re: Keepalive for max_standby_delay  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Mon, Jun 28, 2010 at 3:17 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Wed, 2010-06-16 at 21:56 -0400, Tom Lane wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>> > On Wed, Jun 9, 2010 at 8:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> >> Yes, I'll get with it ...
>>
>> > Any update on this?
>>
>> Sorry, I've been a bit distracted by other responsibilities (libtiff
>> security issues for Red Hat, if you must know).  I'll get on it shortly.
>
> I don't think the PostgreSQL project should wait any longer on this. If
> it does we risk loss of quality in final release, assuming no slippage.

I agree, and had actually been intending to post a similar message in
the next day or two.  We've been waiting for this for nearly a month.

> >From here, I will rework my patch of 31 May to
> * use arrival time on standby as base for max_standby_delay

Assuming that by this you mean, in the case of SR, the time of receipt
of the current WAL chunk, and in the case of the archive, the time of
its acquisition from the archive, +1.

> * make delay apply to both streaming and file cases

+1.

> * min_standby_grace_period - min grace on every query, default 0

I could go either way on this.  +0.5, I guess.

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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: testing plpython3u on 9.0beta2
Next
From: Tom Lane
Date:
Subject: Re: pg_dump's checkSeek() seems inadequate