Re: max_standby_delay considered harmful

Heikki Linnakangas wrote:
> Robert Haas wrote:
>
>> I am not convinced it will be unpredictable. The only caveats that
>> I've seen so far are:
>>
>> - You need to run ntpd.
>> - Queries will get cancelled like crazy if you're not using steaming
>> replication.
>>
>
> And also in situations where the master is idle for a while and then
> starts doing stuff. That's the most significant source of confusion,
> IMHO, I wouldn't mind the requirement of ntpd so much.
>

I consider it mandatory to include an documentation update here that
says "if you set max_standby_delay > 0, and do not run something that
regularly generates activity to the master like [example], you will get
unnecessary query cancellation on the standby". As well as something
like what Josh was suggesting, adding warnings that this is "for
advanced users only", to borrow his wording. This is why my name has
been on the open items list for a while now--to make sure I follow
through on that.

I haven't written it yet because there were still changes to the
underlying code being made up until moments before beta started, then
this discussion started without a break between. There are a clear set
of user land things that can be done to make up the deficiencies in the
state of the server code, but we won't even get to see how they work out
in the field (feedback needed to improve the 9.1 design) if this
capability goes away altogether.

Is it not clear that there are some people who consider the occasional
bit of cancellation OK, because they can correct for at the application
layer and they're willing to factor it in to their design if it allows
using the otherwise idle HA standby? I'm fine with expanding that
section of the documentation too, to make it more obvious that's the
only situation this aspect of HS is aimed at and suitable for.

--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.us