Re: max_standby_delay considered harmful
Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>
From: Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>
To: Simon Riggs <simon@2ndQuadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
Date: 2010-05-03T16:54:05Z
Lists: pgsql-hackers
Simon Riggs wrote: > On Mon, 2010-05-03 at 11:37 -0400, Tom Lane wrote: > >> I've finally wrapped my head around exactly what the max_standby_delay >> code is doing, and I'm not happy with it. > > Yes, I don't think I'd call it perfect yet. > >> have the slave cancel competing queries if the replay process waits >> more than max_standby_delay seconds to acquire a lock. This is simple, >> understandable, and behaves the same whether we're reading live data or >> not. > > I have no objection, and would welcome, adding another behaviour, since > that just gives us a better chance of having this feature do something > useful. > >> I'm inclined to think that we should throw away all this logic > > HS has been through 2 Alphas with the current behaviour and it will go > through 0 Alphas with the newly proposed behaviour. At this stage of > proceedings, that is extremely dangerous and I don't wish to do that. > The likelihood that we replace it with something worse seems fairly > high/certain: snap decision making never quite considers all angles. > Phrases like "throw away all this logic" don't give me confidence that > people that agree with that perspective would understand what they are > signing up to. I'm not really sure how much serious testing outside of the small set of people mostly interested in one or another specific aspect of HS/SR has been actually done with the alphas to be honest. I just started testing HS yesterday and I already ran twice into the general issue tom is complaining about with max_standby_delay... Stefan