On 1/6/15 8:08 PM, Andres Freund wrote: > On 2015-01-05 20:43:12 -0500, Peter Eisentraut wrote: >> For example, putting recovery target parameters into postgresql.conf >> might not make sense to some people. Once you have reached the recovery >> end point, the information is obsolete. Keeping it set could be >> considered confusing. > > I don't know, but I think that ship has sailed. hot_standby, > archive_command, archive_mode, hot_standby_feedback are all essentially > treated differently between primary and standby.
I don't mind those. I mean things like recovery_target_time. >> Moreover, when I'm actually doing point-in-time-recovery attempts, I >> don't think I want to be messing with my pristine postgresql.conf file. >> Having those settings separate isn't a bad idea in that case. > > Well, nothing stops you from having a include file or something similar. Sure, I need to update postgresql.conf to have an include file. > I think we should just make recovery.conf behave exactly the way it does > right now, except parse it according to guc rules. That way the changes > when migrating are minimal and we don't desupport any > usecases. Disallowing that way of operating just seems like > intentionally throwing rocks in the way of getting this done. That was more or less my proposal. >> The current system makes it easy to share postgresql.conf between >> primary and standby and just maintain the information related to the >> standby locally in recovery.conf. pg_basebackup -R makes that even >> easier. It's still possible to do this in the new system, but it's >> decidedly more work. > > Really? Howso? You have to set up include files, override the include file on the standby, I don't know how pg_basebackup -R would even work. And most importantly, you have to come up with all of that yourself, instead of it just working. >> The wins on the other hand are obscure: You can now use SHOW to inspect >> recovery settings. You can design your own configuration file include >> structures to set them. These are not bad, but is that all? > > It's much more: > a) One configuration format instead of two somewhat, but not really, > similar ones. Agreed, but that's also fixable by just changing how recovery.conf is parsed. It doesn't require user space changes. > b) Proper infrastructure to deal with configuration variable boundaries > and such. Just a few days ago there was e7c11887 et al. That's just an implementation issue. > c) Infrastructure for changing settings effective during recovery. Right > now we'd have to rebuild a lot of guc infrasturcture to allow > that. It'd not be that hard to allow changing parameters like > restore_command, primary_conninfo, recovery_target_* et al. That's > for sure not the same commit, but once the infrastructure is in those > won't be too hard. Right, if that worked, then it would be a real win. But this discussion is about right now, and the perspective of the user. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
