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  (Florian Pflug <fgp@phlo.org>)
Список 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 по дате отправления:

Предыдущее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: pg_migrator to /contrib in a later 9.0 beta
Следующее
От: Florian Pflug
Дата:
Сообщение: Re: Partitioning/inherited tables vs FKs