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