Re: max_standby_delay considered harmful
От | Dimitri Fontaine |
---|---|
Тема | Re: max_standby_delay considered harmful |
Дата | |
Msg-id | m21vdkuc2l.fsf@hi-media.com обсуждение исходный текст |
Ответ на | Re: max_standby_delay considered harmful (Florian Pflug <fgp@phlo.org>) |
Ответы |
Re: max_standby_delay considered harmful
|
Список | pgsql-hackers |
Florian Pflug <fgp@phlo.org> writes: > The only remaining option is to continue applying WAL until you reach > a point where no locks are held, then pause. But from a user's POV > that is nearly indistinguishable from simply setting > hot_standby_conflict_winner to in the first place I think. Not really, the use case would be using the slave as a reporting server, you know you have say 4 hours of reporting queries during which you will pause the recovery. So it's ok for the pause command to take time. What I understand the boolean option would do is to force the user into choosing either high-availability or using the slave for other purposes too. The problem is in wanting both, and that's what HS was meant to solve. Having pause/resume allows for a mixed case usage which is simple to drive and understand, yet fails to provide adaptive behavior where queries are allowed to pause recovery implicitly for a while. In my mind, that would be a compromise we could reach for 9.0, but it seems introducing those admin functions now is to far a stretch. I've been failing to understand exactly why, only getting a generic answer I find unsatisfying here, because all the alternative paths being proposed, apart from "improve documentation", are more involved code wise. Regards, -- dim
В списке pgsql-hackers по дате отправления: