Re: Decompression bug in astreamer_lz4
Mikhail Gribkov <youzhick@gmail.com>
From: Mikhail Gribkov <youzhick@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Pg Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-06-27T12:28:18Z
Lists: pgsql-hackers
Attachments
- v2-Fix-lz4-decompressor.patch (application/octet-stream) patch v2
Hi Michael,
> I think that it would be nice to have some test coverage for such
> cases in pg_verifybackup for both the client side and the server side
> of backups compressed, relying on the backend to generate some random
> data dumped into a file at the root of a data folder.
Yes, good point. Added checks to both client and server untar tests.
I also noticed that the problem showup depends on compression level. For
example in 008_untar.pl and 010_client_untar.pl tests it only showed up
with compression levels 0 and 1.
It looks to me that we do not have any chances to check all possible
combinations of vital parameters, but at least we'll check several cases
that we know make a difference.
> I am detecting a threshold close to 512kB to be able to reproduce the
> problem, so we don't need a file that large to see the failure, making
> such tests faster with less data required
I have raised the file size up to 640kB to make it a bit more reliable as
far as we are not sure about all lz4-internals that trigger the problem. It
still does not make the test data unreasonably large.
Attached is the updated version of the patch with test additions.
--
best regards,
Mikhail A. Gribkov
>
Commits
-
Fix bug in archive streamer with LZ4 decompression
- d44efe87ea75 15.14 landed
- 5c639523f721 16.10 landed
- 074003431895 17.6 landed
- d09d1379346e 18.0 landed
- 3369a3b49b0b 19 (unreleased) landed