Re: max_standby_delay considered harmful

Yeb Havinga <yebhavinga@gmail.com>

From: Yeb Havinga <yebhavinga@gmail.com>
To: Rob Wultsch <wultsch@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Bruce Momjian <bruce@momjian.us>, Greg Smith <greg@2ndquadrant.com>, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, Tom Lane <tgl@sss.pgh.pa.us>, Simon Riggs <simon@2ndquadrant.com>, pgsql-hackers@postgresql.org
Date: 2010-05-06T10:08:46Z
Lists: pgsql-hackers
Rob Wultsch wrote:
> I manage a bunch of different environments and I am pretty sure that
> in any of them if the db started seemingly randomly killing queries I
> would have application teams followed quickly by executives coming
> after me with torches and pitchforks.
>
> I can not imagine setting this value to anything other than a bool and
> most of the time that bool would be -1. I would only be unleashing a
> kill storm in utter desperation and I would probably need to explain
> myself in detail after. Utter desperation means I am sure I am going
> to have to do a impactful failover at any moment and need a slave
> completely up to date NOW.
>   
That's funny because when I was reading this thread, I was thinking the 
exact opposite: having max_standby_delay always set to 0 so I know the 
standby server is as up-to-date as possible. The application that 
accesses the hot standby has to be 'special' anyway because it might 
deliver not-up-to-date data. If that information about specialties 
regarding querying the standby server includes the warning that queries 
might get cancelled, they can opt for a retry themselves (is there a 
special return code to catch that case? like PGRES_RETRY_LATER) or a 
message to the user that their report is currently unavailable and they 
should retry in a few minutes.

regards,
Yeb Havinga