pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Don't rely on zlib's gzgetc() macro. 7+ messages / 1 participants [nested] [flat]
* pgsql: Don't rely on zlib's gzgetc() macro. @ 2025-10-19 18:37 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2025-10-19 18:37 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/aa1fcd087e5f709505aa0b9e15c1f3a0ce8b826c Modified Files -------------- src/bin/pg_dump/compress_gzip.c | 9 +++++++++ 1 file changed, 9 insertions(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Don't rely on zlib's gzgetc() macro. @ 2025-10-19 18:37 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2025-10-19 18:37 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/33276cd0272efd72e098840a5f3d3c6b795214c1 Modified Files -------------- src/bin/pg_dump/pg_backup_archiver.h | 10 ++++++++++ 1 file changed, 10 insertions(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Don't rely on zlib's gzgetc() macro. @ 2025-10-19 18:37 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2025-10-19 18:37 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/40dc710a61aa5112b98cdd3d4caca51bd148ffb0 Modified Files -------------- src/bin/pg_dump/pg_backup_archiver.h | 10 ++++++++++ 1 file changed, 10 insertions(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Don't rely on zlib's gzgetc() macro. @ 2025-10-19 18:37 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2025-10-19 18:37 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/277dec6514728e2d0d87c1279dd5e0afbf897428 Modified Files -------------- src/bin/pg_dump/compress_gzip.c | 9 +++++++++ 1 file changed, 9 insertions(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Don't rely on zlib's gzgetc() macro. @ 2025-10-19 18:37 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2025-10-19 18:37 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/c865f5b9f090bc1325f5667b11f883a46f5d96dd Modified Files -------------- src/bin/pg_dump/compress_gzip.c | 9 +++++++++ 1 file changed, 9 insertions(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Don't rely on zlib's gzgetc() macro. @ 2025-10-19 18:37 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2025-10-19 18:37 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/2efca163399ba1be4c2991635960ed509f6e7cfd Modified Files -------------- src/bin/pg_dump/compress_gzip.c | 9 +++++++++ 1 file changed, 9 insertions(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Don't rely on zlib's gzgetc() macro. @ 2025-10-19 18:37 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2025-10-19 18:37 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/8b9924bce7290cd21e816c13f964fe3ba362f526 Modified Files -------------- src/bin/pg_dump/pg_backup_archiver.h | 10 ++++++++++ 1 file changed, 10 insertions(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2025-10-19 18:37 UTC | newest] Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-10-19 18:37 pgsql: Don't rely on zlib's gzgetc() macro. Tom Lane <tgl@sss.pgh.pa.us> 2025-10-19 18:37 pgsql: Don't rely on zlib's gzgetc() macro. Tom Lane <tgl@sss.pgh.pa.us> 2025-10-19 18:37 pgsql: Don't rely on zlib's gzgetc() macro. Tom Lane <tgl@sss.pgh.pa.us> 2025-10-19 18:37 pgsql: Don't rely on zlib's gzgetc() macro. Tom Lane <tgl@sss.pgh.pa.us> 2025-10-19 18:37 pgsql: Don't rely on zlib's gzgetc() macro. Tom Lane <tgl@sss.pgh.pa.us> 2025-10-19 18:37 pgsql: Don't rely on zlib's gzgetc() macro. Tom Lane <tgl@sss.pgh.pa.us> 2025-10-19 18:37 pgsql: Don't rely on zlib's gzgetc() macro. Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox