| From: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
|---|---|
| To: | pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
| Subject: | Skip further compression and writes after LZ4 close failures |
| Date: | 2026-10-12 01:34:08 |
| Message-ID: | B72471BC-D265-4912-8CC6-722B4B8DEA7E@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
While working on patch [1], I spotted that LZ4Stream_close() doesn’t handle failures cleanly.
If fwrite() fails, it sets the success flag to false, but still proceeds to call LZ4F_compressEnd(). And if LZ4F_compressEnd() fails, it still calls fwrite() without advancing state->bufdata. I don’t think this would lead to an incorrect result, as the success flag remains false, but further compression and write attempts after a failure are unnecessary and may produce additional error messages.
Looking at zstd, gzip, and custom-format compression, their close paths don’t have the same issue.
Attached is a simple cleanup patch for LZ4Stream_close(). I don’t think it needs to be back-patched.
[1] https://www.postgresql.org/message-id/5962B878-C43D-4EBC-9E95-1F945CE5E586%40gmail.com
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-Avoid-further-compression-and-writes-after-LZ4-cl.patch | application/octet-stream | 2.2 KB |
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Tender Wang | 2026-10-12 01:22:15 | Wrong results from self-join elimination with inheritance and ONLY |