> On Oct 16, 2026, at 15:27, [email protected] wrote:
>
> 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
>
Hi Stefan,
Thanks for the detailed testing on both platforms.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
