Fix behavior with pg_restore -l and compressed dumps

michaelpq · pull[bot] · commit 8a05748f55d9 · 2024-05-14T00:43:58.000Z
pg_restore -l has always been able to read the TOC data of a dump even if its binary has no support for compression, for both compressed and uncompressed dumps. 5e73a60 has introduced a backward-incompatible behavior by switching a warning to a hard error in the code path reading the header data of a dump, preventing the TOC items to be listed even if pg_restore -l, with no support for compression, is used on a compressed dump. Most modern systems should have support for zlib, but it can be also possible that somebody relies on the past behavior when copying over a dump where binaries are not built with zlib support (most likely some WIN32 flavors these days, though most environments should provide that). There is no easy way to have a regression test for this pattern, as it requires a mix of dump/restore commands with different compilation options, with and without compression. One possibility I see here would be to have a command-line option that enforces a non-compression check for a build that supports compression, but that does not seem worth the cost, either. Reported-by: Justin Pryzby Author: Georgios Kokolatos Discussion: https://postgr.es/m/20230125180020.GF22427@telsasoft.com
diff --git a/src/bin/pg_dump/pg_backup_archiver.c b/src/bin/pg_dump/pg_backup_archiver.c
@@ -3784,7 +3784,7 @@ ReadHead(ArchiveHandle *AH)
 
 #ifndef HAVE_LIBZ
 	if (AH->compression_spec.algorithm == PG_COMPRESSION_GZIP)
-		pg_fatal("archive is compressed, but this installation does not support compression");
+		pg_log_warning("archive is compressed, but this installation does not support compression -- no data will be available");
 #endif
 
 	if (AH->version >= K_VERS_1_4)
