Re: recovery.conf location
От | Robert Haas |
---|---|
Тема | Re: recovery.conf location |
Дата | |
Msg-id | C1055647-CC37-4328-BB8F-F9190D04698F@gmail.com обсуждение исходный текст |
Ответ на | Re: recovery.conf location (Fujii Masao <masao.fujii@gmail.com>) |
Ответы |
Re: recovery.conf location
|
Список | pgsql-hackers |
On Oct 1, 2010, at 5:47 AM, Fujii Masao <masao.fujii@gmail.com> wrote: > On Fri, Oct 1, 2010 at 9:21 AM, Josh Berkus <josh@agliodbs.com> wrote: >> On 9/29/10 7:54 PM, Tom Lane wrote: >>> Robert Haas <robertmhaas@gmail.com> writes: >>>> But that's not what Tom is talking about, I don't think: you might >>>> also want a way to explicitly whack the flag in pg_control around. >>>> That would probably be along the lines of pg_resetxlog. I'm not sure >>>> how much use case there is for such a thing, but if it's needed it's >>>> certainly wouldn't be hard to write. >>> >>> Right, but instead of having to provide such a tool, we could just >>> store the status as a text file. There is a pretty time-honored >>> tradition for that, ya know. >> >> And then move all the other config parameters to postgresql.conf? > > The consensus seems to be to move only parameters for the standby server > (except standby_mode) to postgresql.conf. That is, primary_conninfo and > trigger_file. > >> And >> have PG poll that text file periodically so that you could update it and >> it would fail over? > > Hmm.. instead of that text file (i.e., recovery.conf), trigger file is > periodically polled by the standby server. I'm not sure I understand the point of moving all the parameters except one. ...Robert
В списке pgsql-hackers по дате отправления: