Re: max_standby_delay considered harmful
От | Yeb Havinga |
---|---|
Тема | Re: max_standby_delay considered harmful |
Дата | |
Msg-id | 4BE2952E.3060302@gmail.com обсуждение исходный текст |
Ответ на | Re: max_standby_delay considered harmful (Rob Wultsch <wultsch@gmail.com>) |
Ответы |
Re: max_standby_delay considered harmful
SQLSTATE for Hot Standby cancellation SQLSTATE for Hot Standby cancellation |
Список | 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
В списке pgsql-hackers по дате отправления: