Skip site navigation (1) Skip section navigation (2)

Re: Keepalive for max_standby_delay

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Keepalive for max_standby_delay
Date: 2010-07-02 20:40:58
Message-ID: AANLkTin3_hE8TVO71GzIVBVISaelJNdiS6EJmHaTzlKS@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, Jul 2, 2010 at 4:36 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> I haven't been able to wrap my head around why the delay should be
>> LESS in the archive case than in the streaming case.  Can you attempt
>> to hit me with the clue-by-four?
>
> In the archive case, you're presumably trying to catch up, and so it
> makes sense to kill queries faster so you can catch up.

On the flip side, the timeout for the WAL segment is for 16MB of WAL,
whereas the timeout for SR is normally going to be for a much smaller
chunk (right?).  So even with the same value for both, it seems like
queries will be killed more aggressively during archive recovery.

Even so, it seems useful to have both.

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

In response to

Responses

pgsql-hackers by date

Next:From: David E. WheelerDate: 2010-07-02 20:43:26
Subject: Re: hstore ==> and deprecate =>
Previous:From: Robert HaasDate: 2010-07-02 20:38:06
Subject: Re: hstore ==> and deprecate =>

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group