]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Don't rely on zlib's gzgetc() macro.
authorTom Lane <tgl@sss.pgh.pa.us>
Sun, 19 Oct 2025 18:36:58 +0000 (14:36 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Sun, 19 Oct 2025 18:36:58 +0000 (14:36 -0400)
commit2efca163399ba1be4c2991635960ed509f6e7cfd
tree7cc666968e2fb4b77f257f06869d80904d8e7477
parentd4e8c37cca39362b4281ce254f92ff2fe5a4b4b0
Don't rely on zlib's gzgetc() macro.

It emerges that zlib's configuration logic is not robust enough
to guarantee that the macro will have the same ideas about struct
field layout as the library itself does, leading to corruption of
zlib's state struct followed by unintelligible failure messages.
This hazard has existed for a long time, but we'd not noticed
for several reasons:

(1) We only use gzgetc() when trying to read a manually-compressed
TOC file within a directory-format dump, which is a rarely-used
scenario that we weren't even testing before 20ec99589.

(2) No corruption actually occurs unless sizeof(long) is different
from sizeof(off_t) and the platform is big-endian.

(3) Some platforms have already fixed the configuration instability,
at least sufficiently for their environments.

Despite (3), it seems foolish to assume that the problem isn't
going to be present in some environments for a long time to come.
Hence, avoid relying on this macro.  We can just #undef it and
fall back on the underlying function of the same name.

Author: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/2122679.1760846783@sss.pgh.pa.us
Backpatch-through: 13
src/bin/pg_dump/compress_gzip.c