Ensure pg_ctl behaves sanely when data directory is not specified.

Commit aaa6e1def292cdacb6b27088898793b1b879fedf introduced multiple hazards
in the case where pg_ctl is executed with neither a -D switch nor any
PGDATA environment variable.  It would dump core on machines which are
unforgiving about printf("%s", NULL), or failing that possibly give a
rather unhelpful complaint about being unable to execute "postgres -C",
rather than the logically prior complaint about not being told where the
data directory is.

Edmund Horner's report suggests that there is another, Windows-specific
hazard here, but I'm not the person to fix that; it would in any case only
be significant when trying to use a config-only PGDATA pointer.

diff --git a/src/bin/pg_ctl/pg_ctl.c b/src/bin/pg_ctl/pg_ctl.c
index 38828ec9142bca8ec0b121c0b3ec89550cbe92f3..d7b836762d8a66e9fb0d51156abaa5b28af2498e 100644 (file)
--- a/src/bin/pg_ctl/pg_ctl.c
+++ b/src/bin/pg_ctl/pg_ctl.c
@@ -1902,6 +1902,10 @@ adjust_data_dir(void)
                           *my_exec_path;
        FILE       *fd;
 
+       /* do nothing if we're working without knowledge of data dir */
+       if (pg_config == NULL)
+               return;
+
        /* If there is no postgresql.conf, it can't be a config-only dir */
        snprintf(filename, sizeof(filename), "%s/postgresql.conf", pg_config);
        if ((fd = fopen(filename, "r")) == NULL)
@@ -2188,8 +2192,10 @@ main(int argc, char **argv)
                pg_data = xstrdup(pg_config);
        }
 
+       /* -D might point at config-only directory; if so find the real PGDATA */
        adjust_data_dir();
 
+       /* Complain if -D needed and not provided */
        if (pg_config == NULL &&
                ctl_command != KILL_COMMAND && ctl_command != UNREGISTER_COMMAND)
        {