Discussion #5263
PITRTools ini configuration files are too complex
0%
Description
Since we position PITRTools as a tool to simplify WAL-shipping and replication setup, I though I'd count the number of options once needs to set in PIRTools, against pristine PostgresSQL:
PITRTools:
Archiver: 15
Standby: 31.
Comparing to the pristine PostgreSQL:
primary: (wal_level, archive_mode, archive_command, max_wal_senders) - 4.
standby (most of them belong to recovery.conf): (hot_standby, standby_mode, primary_conninfo, restore_command, archive_cleanup_command): 5
We need to rethink PITRTools configuration options. I've made the first step by splitting them into required and uncommon, and put reasonable defaults for the second ones (i.e. assumed ssh and rsync path is fixed, and there is no need to tweak rsync options or set ssh_debug), but to make the tool easier than pristine PostgreSQL we need to put some code to autodetect some of the parameters (i.e. autodetect things like PostgreSQL version, checkpoint_segments value for 8.2 and below, rsync_version, etc.)
Updated by Joshua Drake almost 12 years ago
I think parameter count as a basis for complexity is rather bizarre. The majority of the settings within the ini files are all but self explanatory. Heck, just yesterday I considered adding another one which would allow us to specify a specific python to use. This is because CentOS 5 still ships with an ancient python and if you install 2.6 from EPEL it is labelled python26.
I would say this, I think it makes sense to say if the parameter is NOT set, then it is assumed to be in a standard fixed place, e.g; the $PATH. Then we can remove the parameters and just document that if they need something special, they can add it to the config file.