Re: Turning recovery.conf into GUCs
От | Josh Berkus |
---|---|
Тема | Re: Turning recovery.conf into GUCs |
Дата | |
Msg-id | 546F8B8B.9020208@agliodbs.com обсуждение исходный текст |
Ответ на | Re: Turning recovery.conf into GUCs (Jaime Casanova <jaime@2ndquadrant.com>) |
Ответы |
Re: Turning recovery.conf into GUCs
|
Список | pgsql-hackers |
On 11/21/2014 10:54 AM, Stephen Frost wrote: > * Josh Berkus (josh@agliodbs.com) wrote: >>> Either way, from the code it is clear that we only stay in recovery if >>> standby_mode is directly turned on. This makes the whole check for a >>> specially named file unnecessary, IMO: we should just check the value of >>> standby_mode (which is off by default). >> >> So, what happens when someone does "pg_ctl promote"? Somehow >> standby_mode needs to get set to "off". Maybe we write "standby_mode = >> off" to postgresql.auto.conf? > > Uhh, and then not work for the sane folks who disable > postgresql.auto.conf? No thanks.. Other ideas then, without reverting to the old system? Being able to promote servers over port 5432 will be a huge advantage for container-based systems, so I don't want to give that up as a feature. >> HOWEVER, there's a clear out for this with conf.d. If we enable conf.d >> by default, then we can simply put recovery settings in conf.d, and >> since that specific file (which can have whatever name the user chooses) >> will not be part of backups, it would have the same advantage as >> recovery.conf, without the drawbacks. > > conf.d is a possibility, but there may be environments where the > postgres users doesn't have access to write into the conf.d directrory.. > Not sure if that'd be an issue for what you're suggesting but wanted to > point it out. It's not a real issue for any use-case I'm currently dealing with. Would this approach break things for other people? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
В списке pgsql-hackers по дате отправления: