In the case of setting pg_ctl for the monitor, it attempts to call pg_ctl --version for the path set in the config file before setting it to the new one. We expect that it would check the one that we are setting, rather than the one in the config file (which may prevent this second issue if it didn't allow one to set to a bad binary).
For example, when set to a non-existent binary:
$ pg_autoctl config get postgresql.pg_ctl --pgdata=monitor
Failed to find executable program at "/usr/local/pgsql-13/bin/pg_ctl_no": No such file or directory14:12:35 44102 ERROR Failed to run "pg_ctl --version" using program "/usr/local/pgsql-13/bin/pg_ctl_no": Undefined error: 0
14:12:35 44102 FATAL Failed to read configuration file "/Users/rheaton/.config/pg_autoctl/Users/rheaton/workspace/data_dirs/pg13/monitor/pg_autoctl.cfg"
updating to an existing one fails via CLI:
pg_autoctl config postgresql.pg_ctl /usr/local/pgsql-13/bin/pg_ctl --pgdata=monitor
Failed to find executable program at "/usr/local/pgsql-13-dup/bin/pg_ctl_no": No such file or directory14:12:35 44102 ERROR Failed to run "pg_ctl --version" using program "/usr/local/pgsql-13-dup/bin/pg_ctl_no": Undefined error: 0
14:12:35 44102 FATAL Failed to read configuration file "/Users/rheaton/.config/pg_autoctl/Users/rheaton/workspace/data_dirs/pg13/monitor/pg_autoctl.cfg"
(Output using PR #811 )
Note: This behavior is not observed for data nodes -- they are able to be updated when the current config is invalid. Unless there is a strong reason for difference, maybe we can utilize the same code path for data & monitor?
In the case of setting
pg_ctl
for the monitor, it attempts to callpg_ctl --version
for the path set in the config file before setting it to the new one. We expect that it would check the one that we are setting, rather than the one in the config file (which may prevent this second issue if it didn't allow one to set to a bad binary).For example, when set to a non-existent binary:
updating to an existing one fails via CLI:
(Output using PR #811 )
Note: This behavior is not observed for data nodes -- they are able to be updated when the current config is invalid. Unless there is a strong reason for difference, maybe we can utilize the same code path for data & monitor?