From: | Andrey Borodin <amborodin86(at)gmail(dot)com> |
---|---|
To: | Jacob Champion <jchampion(at)timescale(dot)com> |
Cc: | Daniil Zakhlystov <usernamedt(at)yandex-team(dot)ru>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
Subject: | Re: libpq compression (part 2) |
Date: | 2022-11-15 03:44:24 |
Message-ID: | CAAhFRxicA=0EBxhJfJJLkP62BKX0_UUWM4uaYj8Gwk54r48TiA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Nov 12, 2022 at 8:04 PM Andrey Borodin <amborodin86(at)gmail(dot)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.
Attachment | Content-Type | Size |
---|---|---|
boom.sql | application/octet-stream | 16.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2022-11-15 04:49:16 | Re: Suppressing useless wakeups in walreceiver |
Previous Message | Thomas Munro | 2022-11-15 03:26:50 | Re: Assertion failure in SnapBuildInitialSnapshot() |