Re: Hot Standby Feedback should default to on in 9.3+

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Hot Standby Feedback should default to on in 9.3+
Date: 2012-12-01 00:13:22
Message-ID: 20121201001322.GD27243@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2012-11-30 22:46:06 +0200, Heikki Linnakangas wrote:
> On 30.11.2012 21:02, Andres Freund wrote:
> >Hi,
> >
> >The subject says it all.
> >
> >There are workloads where its detrimental, but in general having it
> >default to on improver experience tremendously because getting conflicts
> >because of vacuum is rather confusing.
> >
> >In the workloads where it might not be a good idea (very long queries on
> >the standby, many dead tuples on the primary) you need to think very
> >carefuly about the strategy of avoiding conflicts anyway, and explicit
> >configuration is required as well.
> >
> >Does anybody have an argument against changing the default value?
>
> -1. By default, I would expect a standby server to not have any meaningful
> impact on the performance of the master. With hot standby feedback, you can
> bloat the master very badly if you're not careful.

True. But everyone running postgres hopefully knows the problem
already. So that effect is relatively easy to explain.

The other control possibilities we have are rather hard to understand
and to setup in my experience.

> Think of someone setting up a test server, by setting it up as a standby
> from the master. Now, when someone holds a transaction open in the test
> server, you get bloat in the master. Or if you set up a standby for
> reporting purposes - a very common use case - you would not expect a long
> running ad-hoc query in the standby to bloat the master. That's precisely
> why you set up such a standby in the first place.

But you can't do any meaningful reporting without changing the current
variables around this anyway. If you have any writes on the master
barely any significant query ever completes.
The two basic choices we give people suck more imo:
* you setup a large delay: It possibly takes a very long time to catch
up if the primary dies, you don't see any up2date data in later queries
* you abort queries: You can't do any reporting queries

Both are unusable for most scenarios and getting the former just right
is hard.

Imo a default of on works in far more scenarios than the contrary.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2012-12-01 00:22:02 Re: Hot Standby Feedback should default to on in 9.3+
Previous Message Magnus Hagander 2012-12-01 00:11:10 Re: Hot Standby Feedback should default to on in 9.3+