| 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: | Whole Thread | Raw Message | 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() |