Re: Add LZ4 compression in pg_dump
От | Peter Eisentraut |
---|---|
Тема | Re: Add LZ4 compression in pg_dump |
Дата | |
Msg-id | 4336c6e7-df8b-1e96-5408-b16dbc6ca6e0@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Add LZ4 compression in pg_dump (Alexander Lakhin <exclusion@gmail.com>) |
Ответы |
Re: Add LZ4 compression in pg_dump
|
Список | pgsql-hackers |
On 11.03.23 07:00, Alexander Lakhin wrote: > Hello, > 23.02.2023 23:24, Tomas Vondra wrote: >> On 2/23/23 16:26, Tomas Vondra wrote: >>> Thanks for v30 with the updated commit messages. I've pushed 0001 after >>> fixing a comment typo and removing (I think) an unnecessary change in an >>> error message. >>> >>> I'll give the buildfarm a bit of time before pushing 0002 and 0003. >>> >> I've now pushed 0002 and 0003, after minor tweaks (a couple typos etc.), >> and marked the CF entry as committed. Thanks for the patch! >> >> I wonder how difficult would it be to add the zstd compression, so that >> we don't have the annoying "unsupported" cases. > > With the patch 0003 committed, a single warning -Wtype-limits appeared > in the > master branch: > $ CPPFLAGS="-Og -Wtype-limits" ./configure --with-lz4 -q && make -s -j8 > compress_lz4.c: In function ‘LZ4File_gets’: > compress_lz4.c:492:19: warning: comparison of unsigned expression in ‘< > 0’ is always false [-Wtype-limits] > 492 | if (dsize < 0) > | > (I wonder, is it accidental that there no other places that triggers > the warning, or some buildfarm animals had this check enabled before?) I think there is an underlying problem in this code that it dances back and forth between size_t and int in an unprincipled way. In the code that triggers the warning, dsize is size_t. dsize is the return from LZ4File_read_internal(), which is declared to return int. The variable that LZ4File_read_internal() returns in the success case is size_t, but in case of an error it returns -1. (So the code that is warning is meaning to catch this error case, but it won't ever work.) Further below LZ4File_read_internal() calls LZ4File_read_overflow(), which is declared to return int, but in some cases it returns fs->overflowlen, which is size_t. This should be cleaned up. AFAICT, the upstream API in lz4.h uses int for size values, but lz4frame.h uses size_t, so I don't know what the correct approach is.
В списке pgsql-hackers по дате отправления: