Re: On a somewhat disappointing correspondence (was: max_standby_delay considered harmful)
От | Bruce Momjian |
---|---|
Тема | Re: On a somewhat disappointing correspondence (was: max_standby_delay considered harmful) |
Дата | |
Msg-id | 201005060004.o4604JF25539@momjian.us обсуждение исходный текст |
Ответ на | On a somewhat disappointing correspondence (was: max_standby_delay considered harmful) ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: On a somewhat disappointing correspondence
|
Список | pgsql-hackers |
Kevin Grittner wrote: > Simon Riggs <simon@2ndQuadrant.com> wrote: > > I've refrained from comment on max_standby_delay because I have > neither read the patch nor am likely to be an early adopter of HS; > however, as a potential eventual user I have to say that the > semantics for this GUC proposed by Simon seem sane and useful to me. > > Certainly the documentation would need to be clear on the pitfalls > of using something other than 0 or -1, and there were technical > issues raised on the thread outside the scope of the semantics of > the GUC, but the issues around clock sync and transfer time ring of > FUD. We sync our central router to a bank of atomic clocks around > the world, and sync every server to the router -- if a server drifts > we would have much bigger problems than this GUC would pose, so we > monitor that and make loud noises should something drift. > > Are there other controls that would be useful? Undoubtedly. Should > they be added to 9.0? I'm not in a position to say. I don't see > the point of ripping out one potentially useful control, which > *might* be sufficient for 9.0 because someone might choose to use it > inappropriately. Just make sure it's documented well enough. We are not very good at _removing_ functionality/GUCs, and based on the discussion so far, I think there is a very slim chance we would get it right for 9.0, which is why I suggested converting it to a boolean and revisiting this for 9.1. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com
В списке pgsql-hackers по дате отправления: