Re: max_standby_delay considered harmful
От | Dimitri Fontaine |
---|---|
Тема | Re: max_standby_delay considered harmful |
Дата | |
Msg-id | 87ljbxjs8p.fsf@hi-media-techno.com обсуждение исходный текст |
Ответ на | Re: max_standby_delay considered harmful (Greg Smith <greg@2ndquadrant.com>) |
Ответы |
Re: max_standby_delay considered harmful
|
Список | pgsql-hackers |
Greg Smith <greg@2ndquadrant.com> writes: > If you need a script that involves changing a server setting to do > something, that translates into "you can't do that" for a typical DBA. The > idea of a program regularly changing a server configuration setting on a > production system is one you just can't sell. That makes this idea > incredibly more difficult to use in the field than any of the workarounds > that cope with the known max_standby_delay issues. I still think that the best API we can do in a timely fashion for 9.0 is: standby_conflict_winner = replay|queries pg_pause_recovery() / pg_resume_recovery() It seems to me those two functions are only exposing existing facilities in the code, so that's more an API change that a new feature inclusion. Of course I'm certainly wrong. But the code has already been written. I don't think we'll find any better to offer our users in the right time frame. Now I'll try to step back and stop repeating myself in the void :) Regards, -- dim
В списке pgsql-hackers по дате отправления: