On Fri, Nov 30, 2012 at 11:35 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Nov 30, 2012 at 2:02 PM, Andres Freund <andres@2ndquadrant.com> wrote:
>> Does anybody have an argument against changing the default value?
>
> Well, the disadvantage of it is that the standby can bloat the master,
> which might be surprising to some people, too. But I don't really
> have a lot of skin in this game.
Under this precept, we used to not enable hot standby feedback and
instead allowed more or less unbounded staleness of the standby
through very long cancellation times. Although not immediate,
eventually we decided that enough people were getting confused by
sufficiently long standby delay caused by bad queries and idle in xact
backends, so now we have enabled feedback for new database replicants,
along with some fairly un-aggressive cancellation timeouts. It's all
rather messy and not very satisfying. We have yet to know if feedback
causes or solves problems, on average.
In very early versions we tried the default cancellation settings, and
query cancellation confused everyone a *lot*. That went away in a
hurry as a result, so I suppose it's not entirely unreasonable to say
in retrospect that the defaults can be considered kind of bad.
Longer term, I think I'd be keen to switch all our user-controlled
replication to logical except for use cases where the workload of the
standby is under our (and not the user's) control, such as for
failover.
Unfortunately, our experience with the feature and its use suggests
that the contract granted by the mechanisms seen in hot standby are
too complex for full-stack developers to keep in careful consideration
along with all the other things they want to do with their application
and/or have to remember about Postgres to get by.
--
fdr
