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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
