On Thu, 2010-06-03 at 13:32 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
> > On Thu, 2010-06-03 at 12:47 -0400, Tom Lane wrote:
> >> But in any case the current behavior is
> >> still quite broken as regards reading stale timestamps from WAL.
>
> > Agreed. That wasn't the objective of this patch or a priority.
>
> > If you're reading from an archive, you need to set max_standby_delay
> > appropriately, current recommendation is -1.
>
> That's not a fix; the problem is that there *is no* appropriate setting
> for max_standby_delay when you're reading from archive. It is unlikely
> that the values of the timestamps you're reading should be considered to
> have any bearing on what grace period to allow; but nonetheless it's
> desirable to be able to have a non-infinite grace time.
I'm not saying that's a fix; I agree we should change that also.
> Basically what I think is that we want what you called "apply" semantics
> always for reading from archive (and I still think the DBA should be
> able to set that grace period separately from the one that applies in
> SR operation). Paying attention to the master's timestamps is only
> reasonable in the SR context.
Agreed.
> And yes, I want the dependency on WAL timestamps to be gone completely,
> not just mostly. I think that driving the delay logic off of SR receipt
> time (and/or the timestamp we agreed to add to the SR protocol) is the
> appropriate and sufficient way to deal with the problem. Looking at the
> embedded timestamps just confuses the feedback loop behavior.
I disagree with "sufficient", with good reason. Please look at the code
comments and see what will happen if we don't make the correction
suggested. If after that you still disagree, then do it your way and
we'll wait for comments in the beta; I think there will be some, but I
am tired and prone to agreement to allow this to go through.
-- Simon Riggs www.2ndQuadrant.com