Re: max_standby_delay considered harmful
От | Kevin Grittner |
---|---|
Тема | Re: max_standby_delay considered harmful |
Дата | |
Msg-id | 4BE7E24402000025000314AB@gw.wicourts.gov обсуждение исходный текст |
Ответ на | Re: max_standby_delay considered harmful (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: max_standby_delay considered harmful
Re: max_standby_delay considered harmful |
Список | pgsql-hackers |
Bruce Momjian <bruce@momjian.us> wrote: > Robert Haas wrote: >> Overall I would say opinion is about evenly split between: >> >> - leave it as-is >> - make it a Boolean >> - change it in some way but to something more expressive than a >> Boolean I think a boolean would limit the environments in which HS would be useful. Personally, I think how far the replica is behind the source is a more useful metric, even with anomalies on the transition from idle to active; but a blocking duration would be much better than no finer control than the boolean. So my "instant runoff second choice" would be for the block duration knob. > time for a decision, and with no one agreeing on what to do, > feature removal seemed like the best approach. I keep wondering at the assertion that once a GUC is present (especially a tuning GUC like this) that we're stuck with it. I know that's true of SQL code constructs, but postgresql.conf files? How about redirect_stderr, max_fsm_*, sort_mem, etc.? This argument seems tenuous. > Suggesting we will fix it later in beta is not a solution. I'm with you there, 100% -Kevin
В списке pgsql-hackers по дате отправления: