pg_basebackup: Fix a couple of recently-introduced bugs.
authorRobert Haas <rhaas@postgresql.org>
Thu, 27 Jan 2022 14:46:17 +0000 (09:46 -0500)
committerRobert Haas <rhaas@postgresql.org>
Thu, 27 Jan 2022 16:05:48 +0000 (11:05 -0500)
The server expects the compression level to be between 1 and 9, but
Z_DEFAULT_COMPRESSION is -1, so we must not try to send that value
to the server.

Because pg_basebackup's -R option is implemented on the client side,
it can't be used in combination with a backup target. Error out if
someone tries that, instead of silently ignoring the option.

Both issues were reported by Tushar Ahuja; patch by me.

Discussion: http://postgr.es/m/CA+TgmoaMwgdx8HxBjF8hmbohVvPL_0H5LqNrSq0uU+7BKp_Q2A@mail.gmail.com

src/bin/pg_basebackup/pg_basebackup.c

index 46f6f53e9b9dcf0dfccff3924c4a17606f281cb7..851f03ca81a73c8b81b0f3ee63b0231e874883d8 100644 (file)
@@ -1871,6 +1871,12 @@ BaseBackup(void)
            exit(1);
        }
 
+       if (writerecoveryconf)
+       {
+           pg_log_error("recovery configuration cannot be written when a backup target is used");
+           exit(1);
+       }
+
        AppendPlainCommandOption(&buf, use_new_option_syntax, "TABLESPACE_MAP");
 
        if ((colon = strchr(backup_target, ':')) == NULL)
@@ -1913,7 +1919,7 @@ BaseBackup(void)
        }
        AppendStringCommandOption(&buf, use_new_option_syntax,
                                  "COMPRESSION", compressmethodstr);
-       if (compresslevel != 0)
+       if (compresslevel != 0 && compresslevel != Z_DEFAULT_COMPRESSION)
            AppendIntegerCommandOption(&buf, use_new_option_syntax,
                                       "COMPRESSION_LEVEL", compresslevel);
    }