Greg Smith <g...@2ndquadrant.com> writes:
> If the standby is not current, you may not want people to execute
> queries against it. In some situations, returning results against
> obsolete data is worse than not letting the query execute at all. As I
> see it, the current max_standby_delay implementation includes the
> expectation that the results you are getting are no more than
> max_standby_delay behind the master, presuming that new data is still
> coming in. If the standby has really fallen further behind than that,
> there are situations where you don't want it doing anything but catching
> up until that is no longer the case, and you especially don't want it
> returning stale query data.
That is very possibly a useful thing to be able to specify, but the
current implementation has *nothing whatsoever* to do with making such a
guarantee. It will only kill queries that are creating a lock conflict.
I would even argue that it's a bad thing to have a parameter that looks
like it might do that, when it doesn't.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
