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

Re: Keepalive for max_standby_delay

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
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:36:22
Message-ID: 26941.1278102982@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
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.  The existing
code essentially forces instant kill when reading from archive, for any
reasonable value of max_standby_delay (because the archived timestamps
will probably be older than that).  That's overenthusiastic in my view,
but you can get that behavior if you want it with this patch by setting
max_standby_archive_delay to zero.  If you don't want it, you can use
something larger.  If you don't think that max_standby_archive_delay
should be less than max_standby_streaming_delay, you can set them the
same, too.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2010-07-02 20:38:06
Subject: Re: hstore ==> and deprecate =>
Previous:From: Robert HaasDate: 2010-07-02 20:20:46
Subject: Re: Keepalive for max_standby_delay

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