Re: libpq compression (part 2)
| От | Andrey Borodin |
|---|---|
| Тема | Re: libpq compression (part 2) |
| Дата | |
| Msg-id | CAAhFRxicA=0EBxhJfJJLkP62BKX0_UUWM4uaYj8Gwk54r48TiA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: libpq compression (part 2) (Andrey Borodin <amborodin86@gmail.com>) |
| Ответы |
Re: libpq compression (part 2)
|
| Список | pgsql-hackers |
On Sat, Nov 12, 2022 at 8:04 PM Andrey Borodin <amborodin86@gmail.com> wrote: > > While testing patch some more I observe unpleasant segfaults: > > #27 0x000000000b08fda2 in lz4_decompress (d_stream=0x18cf82a0, > src=0x7feae4fa505d, src_size=92, > (gdb) select-frame 27 > (gdb) info locals > ds = 0x18cf82a0 > decPtr = 0x18cf8aec "" > decBytes = -87 > I've debugged the stuff and the problem resulted to be in wrong message limits for Lz4 compression +#define MESSAGE_MAX_BYTES 819200 instead of +#define MESSAGE_MAX_BYTES 8192 Other codecs can utilize continuation of the decompression stream using ZS_DATA_PENDING, while Lz4 cannot do this. I was going to produce quickfix for all my lz4 findings, but it occured to me that a patchset needs a heavy rebase. If no one shows up to fix it I'll do that in one of the coming weekends. Either way here's a reproducer for the coredump: psql 'compression=lz4' -f boom.sql Thanks! Best regards, Andrey Borodin.
Вложения
В списке pgsql-hackers по дате отправления: