On Oct 15, 2026, Chao Li <[email protected]> wrote: >> @Stefan, would you please help verify the fix on your end? > > PFA v2 - fix the CI failures.
Hi Chao, Thanks a lot for the quick fix. I tested v2 on master (a999971) on Debian 13 and on Windows 11, both built from source (on Windows with MSVC 19.51 and meson). zlib 1.3.2 was the default. For the end-to-end runs I also swapped in 1.3.1 and the current zlib develop branch: via LD_LIBRARY_PATH on Linux, and on Windows by putting zlib1.dll next to pg_restore.exe, as in the EDB packages. TAP: with only 0001 applied, 007_pg_dump_gzip fails as expected on both systems (tests 5 and 7). With 0001 and 0002 it passes on both, and so does the rest of the pg_dump suite on Linux. End-to-end, restoring into a database (--section=data), a table of 20001 rows whose uncompressed data is a multiple of 128 kB, with the same results on both systems: - intact file, csize % 8192 == 0: unpatched master fails; with v2 all 20001 rows are restored with zlib 1.3.2, 1.3.1 and develop - one more gzip header byte: 20001 rows with and without v2 - data file cut in half: v2 reports "compressed stream is incomplete" with all three zlib versions; without the patch, see below On the intact file, unpatched master fails with "could not close data file ...: Success" on Linux and "...: No error" on Windows, the message we saw in production. With zlib 1.3.1 next to it, unpatched master restores the same file without complaint. Without the patch, what happens to the truncated file depends on where the cut lands. In these runs the server rejected the incomplete last line; in an earlier run with 18.6 the restore loaded 10073 of 20001 rows and exited 0. I also restored a whole dump with -j 4 that contains the boundary file, an empty table (25-byte data file), and an empty and a non-empty large object (the empty one is a 20-byte member). With v2 everything is restored on both systems: 20001 rows, 0 rows, and large objects of 0 and 50000 bytes. Unpatched master fails with the same "could not close data file" error, followed by "a worker process died unexpectedly". So the empty-member case that caused trouble in the zstd/LZ4 change looks fine here. The stricter parsing (zero-byte files and trailing bytes after the last member are now errors) is fine from our side, because pg_dump always writes at least an empty member. I think this would be worth back-patching. With zlib 1.3.2, pg_restore rejects intact dumps, and the Windows binaries of 14 to 18 ship that version (in 18.6 it is linked statically into pg_dump and pg_restore). The November 12 release is also the last one for 14. I realize that 14 and 15 do not have compress_gzip.c yet, so they would need their own version of the fix. In 14 to 18, pg_restore reads in 4096-byte chunks; the test's 128 kB alignment is a multiple of that, so the test should catch the problem there as well. Regards, Stefan Graßl
