Re: astreamer_lz4: fix bug of output pointer advancement in decompressor
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Chao Li <li.evan.chao@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@lists.postgresql.org>,
Robert Haas <robertmhaas@gmail.com>
Date: 2026-03-04T17:16:55Z
Lists: pgsql-hackers
Chao Li <li.evan.chao@gmail.com> writes:
> There have been a couple of LZ4-related patches recently, so I spent some time playing with the LZ4 path and found a bug in astreamer_lz4_decompressor_content().
Yup, that's clearly wrong. I failed to reproduce a crash with the
test hack you suggested, but no matter. Pushed with some cosmetic
editorialization.
The track record of all this client-side-compression logic is
really quite awful :-(. Another thing that I'm looking askance
at is the error handling, or rather lack of it:
ret = LZ4F_decompress(mystreamer->dctx,
next_out, &out_size,
next_in, &read_size, NULL);
if (LZ4F_isError(ret))
pg_log_error("could not decompress data: %s",
LZ4F_getErrorName(ret));
... continue on our merry way ...
I suspect whoever wrote this thought pg_log_error is equivalent
to elog(ERROR), but it's not; it just prints a message. It seems
highly unlikely to me that continuing onwards will result in a
good outcome. I'm a bit inclined to s/pg_log_error/pg_fatal/
throughout these files, at least in places where there's no
visible effort to handle the error.
regards, tom lane
Commits
-
Exit after fatal errors in client-side compression code.
- cce939c71c11 16.14 landed
- ac0accafd6b6 19 (unreleased) landed
- a01a592b1193 18.4 landed
- 9a42888a32fd 15.18 landed
- 8b198b093fd2 17.10 landed
-
Fix yet another bug in archive streamer with LZ4 decompression.
- c70f6dc6bd79 19 (unreleased) landed
- 78dc9a808201 18.4 landed
- 4548e8746631 15.18 landed
- 415cc943ffdd 16.14 landed
- 2640c5ba772e 17.10 landed