pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Fix issue with reading zero bytes in Gzip_read. 4+ messages / 1 participants [nested] [flat]
* pgsql: Fix issue with reading zero bytes in Gzip_read. @ 2025-10-13 16:44 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 4+ messages in thread From: Tom Lane @ 2025-10-13 16:44 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix issue with reading zero bytes in Gzip_read. pg_dump expects a read request of zero bytes to be a no-op; see for example ReadStr(). Gzip_read got this wrong and falsely supposed that the resulting gzret == 0 indicated an error. We could complicate that error-checking logic some more, but it seems best to just fall out immediately when passed size == 0. This bug breaks the nominally-supported case of manually gzip'ing the toc.dat file within a directory-style dump, so back-patch to v16 where this code came in. (Prior branches already have a short-circuit for size == 0 before their only gzread call.) Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Discussion: https://postgr.es/m/3515357.1760128017@sss.pgh.pa.us Backpatch-through: 16 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/a239c4a0c22627a45c0a91d2f4d9755bbc5be7be Modified Files -------------- src/bin/pg_dump/compress_gzip.c | 4 ++++ 1 file changed, 4 insertions(+) ^ permalink raw reply [nested|flat] 4+ messages in thread
* pgsql: Fix issue with reading zero bytes in Gzip_read. @ 2025-10-13 16:44 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 4+ messages in thread From: Tom Lane @ 2025-10-13 16:44 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix issue with reading zero bytes in Gzip_read. pg_dump expects a read request of zero bytes to be a no-op; see for example ReadStr(). Gzip_read got this wrong and falsely supposed that the resulting gzret == 0 indicated an error. We could complicate that error-checking logic some more, but it seems best to just fall out immediately when passed size == 0. This bug breaks the nominally-supported case of manually gzip'ing the toc.dat file within a directory-style dump, so back-patch to v16 where this code came in. (Prior branches already have a short-circuit for size == 0 before their only gzread call.) Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Discussion: https://postgr.es/m/3515357.1760128017@sss.pgh.pa.us Backpatch-through: 16 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/6a4009747c3687bf1fdfef5f0b75c33681f37a10 Modified Files -------------- src/bin/pg_dump/compress_gzip.c | 4 ++++ 1 file changed, 4 insertions(+) ^ permalink raw reply [nested|flat] 4+ messages in thread
* pgsql: Fix issue with reading zero bytes in Gzip_read. @ 2025-10-13 16:44 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 4+ messages in thread From: Tom Lane @ 2025-10-13 16:44 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix issue with reading zero bytes in Gzip_read. pg_dump expects a read request of zero bytes to be a no-op; see for example ReadStr(). Gzip_read got this wrong and falsely supposed that the resulting gzret == 0 indicated an error. We could complicate that error-checking logic some more, but it seems best to just fall out immediately when passed size == 0. This bug breaks the nominally-supported case of manually gzip'ing the toc.dat file within a directory-style dump, so back-patch to v16 where this code came in. (Prior branches already have a short-circuit for size == 0 before their only gzread call.) Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Discussion: https://postgr.es/m/3515357.1760128017@sss.pgh.pa.us Backpatch-through: 16 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/bf18e9bd70decd294a9be517cb5b3a260ccfdd15 Modified Files -------------- src/bin/pg_dump/compress_gzip.c | 4 ++++ 1 file changed, 4 insertions(+) ^ permalink raw reply [nested|flat] 4+ messages in thread
* pgsql: Fix issue with reading zero bytes in Gzip_read. @ 2025-10-13 16:44 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 4+ messages in thread From: Tom Lane @ 2025-10-13 16:44 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix issue with reading zero bytes in Gzip_read. pg_dump expects a read request of zero bytes to be a no-op; see for example ReadStr(). Gzip_read got this wrong and falsely supposed that the resulting gzret == 0 indicated an error. We could complicate that error-checking logic some more, but it seems best to just fall out immediately when passed size == 0. This bug breaks the nominally-supported case of manually gzip'ing the toc.dat file within a directory-style dump, so back-patch to v16 where this code came in. (Prior branches already have a short-circuit for size == 0 before their only gzread call.) Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Discussion: https://postgr.es/m/3515357.1760128017@sss.pgh.pa.us Backpatch-through: 16 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/1518b7d76aadcbdffa6214555b82b995e7404b38 Modified Files -------------- src/bin/pg_dump/compress_gzip.c | 4 ++++ 1 file changed, 4 insertions(+) ^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2025-10-13 16:44 UTC | newest] Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-10-13 16:44 pgsql: Fix issue with reading zero bytes in Gzip_read. Tom Lane <tgl@sss.pgh.pa.us> 2025-10-13 16:44 pgsql: Fix issue with reading zero bytes in Gzip_read. Tom Lane <tgl@sss.pgh.pa.us> 2025-10-13 16:44 pgsql: Fix issue with reading zero bytes in Gzip_read. Tom Lane <tgl@sss.pgh.pa.us> 2025-10-13 16:44 pgsql: Fix issue with reading zero bytes in Gzip_read. 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