pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Exit after fatal errors in client-side compression code. 5+ messages / 1 participants [nested] [flat]
* pgsql: Exit after fatal errors in client-side compression code. @ 2026-03-05 19:43 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 5+ messages in thread From: Tom Lane @ 2026-03-05 19:43 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Exit after fatal errors in client-side compression code. It looks like whoever wrote the astreamer (nee bbstreamer) code thought that pg_log_error() is equivalent to elog(ERROR), but it's not; it just prints a message. So all these places tried to continue on after a compression or decompression error return, with the inevitable result being garbage output and possibly cascading error messages. We should use pg_fatal() instead. These error conditions are probably pretty unlikely in practice, which no doubt accounts for the lack of field complaints. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Discussion: https://postgr.es/m/1531718.1772644615@sss.pgh.pa.us Backpatch-through: 15 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/a01a592b1193c4a22d897393d664f5888f7a25b5 Modified Files -------------- src/bin/pg_dump/compress_lz4.c | 13 +++++++++++-- src/fe_utils/astreamer_gzip.c | 2 +- src/fe_utils/astreamer_lz4.c | 20 ++++++++++---------- src/fe_utils/astreamer_zstd.c | 19 ++++++++----------- 4 files changed, 30 insertions(+), 24 deletions(-) ^ permalink raw reply [nested|flat] 5+ messages in thread
* pgsql: Exit after fatal errors in client-side compression code. @ 2026-03-05 19:43 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 5+ messages in thread From: Tom Lane @ 2026-03-05 19:43 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Exit after fatal errors in client-side compression code. It looks like whoever wrote the astreamer (nee bbstreamer) code thought that pg_log_error() is equivalent to elog(ERROR), but it's not; it just prints a message. So all these places tried to continue on after a compression or decompression error return, with the inevitable result being garbage output and possibly cascading error messages. We should use pg_fatal() instead. These error conditions are probably pretty unlikely in practice, which no doubt accounts for the lack of field complaints. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Discussion: https://postgr.es/m/1531718.1772644615@sss.pgh.pa.us Backpatch-through: 15 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/9a42888a32fd2ebc3d8e39bbc450556c326c9db7 Modified Files -------------- src/bin/pg_basebackup/bbstreamer_gzip.c | 2 +- src/bin/pg_basebackup/bbstreamer_lz4.c | 20 ++++++++++---------- src/bin/pg_basebackup/bbstreamer_zstd.c | 12 ++++++------ 3 files changed, 17 insertions(+), 17 deletions(-) ^ permalink raw reply [nested|flat] 5+ messages in thread
* pgsql: Exit after fatal errors in client-side compression code. @ 2026-03-05 19:43 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 5+ messages in thread From: Tom Lane @ 2026-03-05 19:43 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Exit after fatal errors in client-side compression code. It looks like whoever wrote the astreamer (nee bbstreamer) code thought that pg_log_error() is equivalent to elog(ERROR), but it's not; it just prints a message. So all these places tried to continue on after a compression or decompression error return, with the inevitable result being garbage output and possibly cascading error messages. We should use pg_fatal() instead. These error conditions are probably pretty unlikely in practice, which no doubt accounts for the lack of field complaints. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Discussion: https://postgr.es/m/1531718.1772644615@sss.pgh.pa.us Backpatch-through: 15 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/8b198b093fd2ccc2712f6b5a43665818310698f4 Modified Files -------------- src/bin/pg_basebackup/bbstreamer_gzip.c | 2 +- src/bin/pg_basebackup/bbstreamer_lz4.c | 20 ++++++++++---------- src/bin/pg_basebackup/bbstreamer_zstd.c | 19 ++++++++----------- src/bin/pg_dump/compress_lz4.c | 13 +++++++++++-- 4 files changed, 30 insertions(+), 24 deletions(-) ^ permalink raw reply [nested|flat] 5+ messages in thread
* pgsql: Exit after fatal errors in client-side compression code. @ 2026-03-05 19:43 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 5+ messages in thread From: Tom Lane @ 2026-03-05 19:43 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Exit after fatal errors in client-side compression code. It looks like whoever wrote the astreamer (nee bbstreamer) code thought that pg_log_error() is equivalent to elog(ERROR), but it's not; it just prints a message. So all these places tried to continue on after a compression or decompression error return, with the inevitable result being garbage output and possibly cascading error messages. We should use pg_fatal() instead. These error conditions are probably pretty unlikely in practice, which no doubt accounts for the lack of field complaints. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Discussion: https://postgr.es/m/1531718.1772644615@sss.pgh.pa.us Backpatch-through: 15 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/ac0accafd6b6eef1a86a50f42346e1e926505df2 Modified Files -------------- src/bin/pg_dump/compress_lz4.c | 14 ++++++++++++-- src/fe_utils/astreamer_gzip.c | 2 +- src/fe_utils/astreamer_lz4.c | 20 ++++++++++---------- src/fe_utils/astreamer_zstd.c | 19 ++++++++----------- 4 files changed, 31 insertions(+), 24 deletions(-) ^ permalink raw reply [nested|flat] 5+ messages in thread
* pgsql: Exit after fatal errors in client-side compression code. @ 2026-03-05 19:43 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 5+ messages in thread From: Tom Lane @ 2026-03-05 19:43 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Exit after fatal errors in client-side compression code. It looks like whoever wrote the astreamer (nee bbstreamer) code thought that pg_log_error() is equivalent to elog(ERROR), but it's not; it just prints a message. So all these places tried to continue on after a compression or decompression error return, with the inevitable result being garbage output and possibly cascading error messages. We should use pg_fatal() instead. These error conditions are probably pretty unlikely in practice, which no doubt accounts for the lack of field complaints. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Discussion: https://postgr.es/m/1531718.1772644615@sss.pgh.pa.us Backpatch-through: 15 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/cce939c71c11e9434d96c60977bc805682f3d18d Modified Files -------------- src/bin/pg_basebackup/bbstreamer_gzip.c | 2 +- src/bin/pg_basebackup/bbstreamer_lz4.c | 20 ++++++++++---------- src/bin/pg_basebackup/bbstreamer_zstd.c | 19 ++++++++----------- src/bin/pg_dump/compress_lz4.c | 13 +++++++++++-- 4 files changed, 30 insertions(+), 24 deletions(-) ^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2026-03-05 19:43 UTC | newest] Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-03-05 19:43 pgsql: Exit after fatal errors in client-side compression code. Tom Lane <tgl@sss.pgh.pa.us> 2026-03-05 19:43 pgsql: Exit after fatal errors in client-side compression code. Tom Lane <tgl@sss.pgh.pa.us> 2026-03-05 19:43 pgsql: Exit after fatal errors in client-side compression code. Tom Lane <tgl@sss.pgh.pa.us> 2026-03-05 19:43 pgsql: Exit after fatal errors in client-side compression code. Tom Lane <tgl@sss.pgh.pa.us> 2026-03-05 19:43 pgsql: Exit after fatal errors in client-side compression code. 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