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);
        }