Fix behavior with pg_restore -l and compressed dumps 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/[email protected] Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/783d8abc3b63267194ca21b679caf8d152b93358 Modified Files -------------- src/bin/pg_dump/pg_backup_archiver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
