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
