| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
| Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Keepalive for max_standby_delay |
| Date: | 2010-06-03 16:58:45 |
| Message-ID: | 6558.1275584325@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> On Wed, 2010-06-02 at 16:00 -0400, Tom Lane wrote:
>> the current situation that query grace periods go to zero
> Possibly a better way to handle this concern is to make the second
> parameter: min_standby_grace_period - the minimum time a query will be
> given in which to execute, even if max_standby_delay has been reached or
> exceeded.
> Would that more directly address you concerns?
> min_standby_grace_period (ms) SIGHUP
A minimum grace period seems like a good idea to me, but I think it's
somewhat orthogonal to the core problem here. I think we all
intuitively feel that there should be a way to dial back the grace
period when a slave is "far behind" on applying WAL. The problem is
first how to figure out what "far behind" means, and second how to
adjust the grace period in a way that doesn't have surprising
misbehaviors. A minimum grace period would prevent some of the very
worst misbehaviors but it's not really addressing the core problem.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2010-06-03 17:00:49 | Re: Did we really want to force an initdb in beta2? |
| Previous Message | Tom Lane | 2010-06-03 16:47:47 | Re: Keepalive for max_standby_delay |