Re: max_standby_delay considered harmful
От | Dimitri Fontaine |
---|---|
Тема | Re: max_standby_delay considered harmful |
Дата | |
Msg-id | m2k4rdwaix.fsf@hi-media.com обсуждение исходный текст |
Ответ на | Re: max_standby_delay considered harmful (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: max_standby_delay considered harmful
|
Список | pgsql-hackers |
Tom Lane <tgl@sss.pgh.pa.us> writes: > I like the proposal of a boolean because it provides only the minimal > feature set of two cases that are both clearly needed and easily > implementable. Whatever we do later is certain to provide a superset > of those two cases. If we do something else (and that includes my own > proposal of a straight lock timeout), we'll be implementing something > we might wish to take back later. Taking out features after they've > been in a release is very hard, even if we realize they're badly > designed. That's where I though my proposal fitted in. I fail to see us wanting to take back explicit pause/resume admin functions in any future release. Now, after having read Greg's arguments, my vote would be the following:- hot_standby_conflict_winner = queries|replay, defaultsto replay- add pause/resume so that people can switch temporarily to queries- label max_standby_delay *experimental*,keep current code By clearly stating the feature is *experimental* it should be easy to both get feedback on it so that we know what to implement in 9.1, and should that be completely different, take back the feature. It should even be possible to continue tweaking its behavior during beta, or do something better. Of course it will piss off some users, but they knew they were depending on some *experimental* feature after all. Regards, -- dim
В списке pgsql-hackers по дате отправления: