unite recovery.conf and postgresql.conf
От | Fujii Masao |
---|---|
Тема | unite recovery.conf and postgresql.conf |
Дата | |
Msg-id | CAHGQGwHi=4GV6neLRXF7rexTBkjhcAEqF9_xq+tRvFv2bVd59w@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: unite recovery.conf and postgresql.conf
Re: unite recovery.conf and postgresql.conf |
Список | pgsql-hackers |
Hi, http://archives.postgresql.org/pgsql-hackers/2010-12/msg02343.php In previous discussion, we've reached the consensus that we should unite recovery.conf and postgresql.conf. The attached patch does that. The patch is WIP, I'll have to update the document, but if you notice something, please feel free to comment. This patch allows us to specify recovery parameters like primary_conninfo in postgresql.conf. You can change some of them without restarting the server (i.e., by using "pg_ctl reload") and see the current settings by SHOW command. But note that recovery.conf is still required as a status file for archive recovery and standby server even if you put all the settings in postgresql.conf. Recovery parameters in postgresql.conf only have effect when recovery.conf exists. For backward compatibility, this patch still allows us to specify recovery parameters in recovery.conf. But, as in past years, you cannot reload recovery.conf and see the current settings by SHOW command. We should recommend to put all the settings in postgresql.conf and empty recovery.conf, but you can also put all recovery parameters in recovery.conf. If the same parameter is specified in both file, the setting in recovery.conf overrides that in postgresql.conf. In this case, SHOW command displays the settings in postgresql.conf even though they are not used at all. Even if you change the settings in postgresql.conf and reload it, they have no effect because the settings in recovery.conf are used preferentially. These limitations on recovery.conf might confuse users. But since most users will put all the settings in postgresql.conf if we recommend to do that, I don't think that it's worth complicating the source code for getting rid of those limitations. Thought? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
Вложения
В списке pgsql-hackers по дате отправления: